The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Everything with a table

I have this co-worker that insists in solving every design problem with a database table. The current project is a multiuser desktop application that uses a database server and contains many different services like messaging and reporting.

Now, this person insists that all these services can be implemented using a combination tables and stored procs and this seems to me as the hammer and nails syndrome.

The first problem I envisage with this kind of approach is bad performance and high latency but when I put this forward I am asked to prove it. As we haven't start implementing the product it is difficult to do it. My point is that the design should be less dependent on the database specially for the desktop part of the app and things like queues and security.

Am I right in thinking that certain problems don't lend themselves to such a simplistic approach or is it really feasible to rely on the database server for user file storage, user profiles, authentication and authorization, messaging and notification, amognst others?
design challenged
Sunday, January 16, 2005
It depends. Generally RDBMSs can be used for a lot of stuff. With transactions, concurrency handling, enforcing data integrity, it's a good fallback. The database could be accessed from different languages/systems and handle that just fine.

If you use Java, then there are some abstractions that are available, like EJBs and all the accompanying stuff, but they could become the bottle-neck, for example.

Microsoft used to advise to put as much as possible in the database, and use stored procedures freely. But now that they  have an OO environment, they have been joined by some OO purists that may want to change some old rules. :P

So, it depends. If you were Google, you could even use RAM memory to store your data for fast access. :-)
Sunday, January 16, 2005
>  I am asked to prove it.

This is good advice. In general one can't argue with general misapprehensions. One can't argue against a non-proposal. What would you rather do? How would it perform better? How would it make you less dependent? The database has a lot of plusses about it. It's backed up, can be replicated, is universally accessable, xfering data isn't that slow, etc etc
Anythink you propose will have ups and downs, how do they compare?
son of parnas
Sunday, January 16, 2005
son of parnas... point taken but for the sake of an example, why use MSMQ or MQ Series when you can put together a simple solution using a database? Or why not use a database server as an email server? This is the crux of the problem.

Also the reverse question can be made: How do we prove that the database solution will perform without building it?

In the end, my question is how flexible is a database and why aren't all those services already implemented in/as database servers. That is what is worriyng me. Why app servers and mail servers exist if it is simple to devise an equivalent based on a database?

It may happen that I am just being an OO purist as Yeah says and that is what I am trying to determine :)
design challenged
Sunday, January 16, 2005
I've used databases for small scale messaging systems.

I'd recommend being careful about getting tied into a particular vendor though...
KC Send private email
Sunday, January 16, 2005
> Why app servers and mail servers exist if it is simple
> to devise an equivalent based on a database?

App servers run the behaviour of the application. Most of them use something like hibernate to talk to something like mysql. When used for web stuff they prefer stateless architectures so the app server is some what wasted imho. The database generally just stores the data. Stored procedures are in the database behaviour realm, but they usually are just more sophisticated data manipulation routines.

You know its fast enough by how you know everything else:
0. know your requirements
1. experience
2. testing
3. have a backup plan in case you are wrong

There's no reason not to use a database for a mail server that i can see. A lot of email servers were built before free good databases were available so the file system was a natural match.
son of parnas
Sunday, January 16, 2005
I am just putting the finishing touches on an Email server module that I built for our main platform. It consists of 5 tables:


The windows service that takes care of sending/receiving only uses the Email table to check for outgoing messages right now, so a client application has to put a record in the database to send a message. However, I can expand that in the future to also use whatever network protocol I want (SOAP, MSMQ, etc) to send/receive messages.
Wayne Send private email
Sunday, January 16, 2005
design challenged,

Some decent rules of thumb I use to determine whether a database ought to be used to store certain data are these:

It probably belongs in a database if...
...the data you require varies based on a parameter you pass
...the data you require varies over time
...the data you require consists of more than one value of the same name and type

It probably belongs in one or more constants, a config file or a base class if...
...the data you require represents a static, business rule

To sum up: things that vary belong in a database; things that do not, don't.
Chris Send private email
Sunday, January 16, 2005
DC, if you looked at MSMQ and MQ series, you will find a DBMS behind them.

Another advantage of using a DBMS of any kind is that they have put a lot of time, effort and debugging into making that "filing cabinet" work reliably.

By re-using an existing system, you can spend less time re-inventing the wheel.

In the end, it is your company, not mine, so you get to make your design and implementation schemes. Here is a quick question: what happens if someone pulls the power cord from your server? How much will be lost forever, how much can be recover?
Sunday, January 16, 2005
You speaking of database vs. queue?

depends: if your database goes down and you have a queue, then you just saved yourself, the data queue's up until the database comes back up.

Guess I look at it from what type of up-time requirements you have.

If you have no such requirement, go to the database, databases are great  :)
Sunday, January 16, 2005
What Peter said  :)

He is right, if it's a bank transaction, you better have a solution to handle that pulled cord!!!

Otherwise you are wasting your customer/company's money coming up with an overly complex solution?
Sunday, January 16, 2005
'To sum up: things that vary belong in a database; things that do not, don't. '

Good advice. You have to think of the alternative. If you have

if this:
do that
do something else.

Every time I've thought 'there'll never be another case' there is. So no hard coded values. But you knew that already.

Table driven methods sounds good to me. It gives you somewhere to load your global variables from (!) if nothing else. And a config file is just a little specialised table.

I would TRY to use database tables whenever possible. Pretend all you've got is a hammer, at least for a while.
Jo Davis
Sunday, January 16, 2005
Some random thoughts -

questions to answer before Using an SQL DB
1. does your data need to have integrity maintained?
2. do you need to give others general search ability?
3. Do you need transactions
4  Do you need loads of extra safeguards against data loss?
5. who'll administer this DB?  optimize?  backup? 

If you don't need these (and others I'm missing ...) you can use something like BerkeleyDB (if you need a DB at all)

whether something should be in a DB at all, instead of in an application ... some other questions

1. who's going to maintain this DB?  If no one's available to do that , you can't really think about an SQL DB.  Having an app not use a DB at all is much easier.

2. if you decide on a DB vendor, will you still be required to maintain vendor independence?  You've just doubled (sometimes more, hahahaha) your database work.  Why more than double?  All the subtle little things you need to debug & add extra code for add up in the end.  And those are sometimes most of the work.
Sanjeev Sharma
Tuesday, January 18, 2005
Thank you all for your comments.

I still am not convinced that, apart from hearsay and aparent simplicity, a database server is the correct choice if what you need is some other funcionality that, incidentally, saves or manipulates data in an hierarchical/relational way.

If I want to send email or serve web pages then I should create/buy an email server or a web server, respectively.

It definitely seems a good choice if you are talking about small products as some posters explained. But, if the point is not reinventing the wheel then do not replicate a message queue with a database: use MSMQ or MQSeries (and you will find a lot more than a database in them). I think this is valid for all the other examples.

I guess that there isn't a definite and straightforward design reason why. I did not find one so far, apart from possible scaleability issues.

But I am trying Ringo :)
design challenged
Tuesday, January 18, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz