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.

..to 'Database purist'..

"Stupid idea.

What is it with you programmers? Why do you always think you can improve on crappy relational databases?

The relational model and approach might not be perfect, but it's the best we've got.

Now will you all stop dicking around, trying to bypass it. Tables, referential integrity, the normal forms and all that tedious stuff. It works. And the better you use it, the better it works.

If you've got such a problem with RDBMS then just use a frigging text file to keep you information in. "

You have just made my day.

Thank you.
D in PHX Send private email
Friday, April 28, 2006
 
 
Amen brother!
Sgt.Sausage
Friday, April 28, 2006
 
 
Ben Bryant
Friday, April 28, 2006
 
 
Here's one that I wrote today:

"I think that the current trend in N-tier to have a database backend and a DAL layer isn't enough.

I think what would solve 99% of everyone's database problems would be to have separate developers for databases and FE code.

Or at least have the FE developers that are "playing DBA" get some decent training.

Here a simple rule of thumb: No SQL anywhere but the database."
D in PHX Send private email
Friday, April 28, 2006
 
 
I've been on both sides of the fence. In my experience doing FE development, the only time I would even consider the possibility of using a flat file was if I was guaranteed that I would never have another app needing to get to the data.

(decent article in the link above, BTW)
D in PHX Send private email
Friday, April 28, 2006
 
 
Flat files rule...in hell.
son of parnas
Friday, April 28, 2006
 
 
"I think what would solve 99% of everyone's database problems would be to have separate developers for databases and FE code."

So that you need at least two developers any time you want to make a significant change or understand a complex problem? That wouldn't solve any of MY problems. No, thanks.

Yeah, I know. Lots of companies do this and it works for them. I'm glad I never had to work at any of them. It would drive me nuts to be constantly waiting for stuff from other people. It's bad enough as it is.
NetFreak Send private email
Friday, April 28, 2006
 
 
Chuck Norris once built an entire enterprise CRM that was backed by a single flat file.  The contents of that file? Just the word "Chuck".
DamnDirtyApe
Friday, April 28, 2006
 
 
...and if you tried to lock the file you'd get a roundhouse kick to the head.
!
Saturday, April 29, 2006
 
 
"
Here a simple rule of thumb: No SQL anywhere but the database."

Please explain this.  Are you advocating stored procedures instead of having SQL in the DAL?
Vince
Saturday, April 29, 2006
 
 
Relational databases are what we have. With the advent of XML, we do see some strong tendencies of multi-value systems to come back into play.

In fact, the best approach seems to be a high performance system, but one that allows some type of multi-valued fields. I write about such systems here

http://www.members.shaw.ca/AlbertKallal/Articles/fog0000000006.html

While I use sql and “so called” relational databases everyday…I also use multi-valued ones..and they quite impressive.

MOST vendors of multi-valued systems allow mapping of these mv tables to sql anyway. This mapping is usually needed to use existing tools and reporting systems.

If you not used anything else then a standard relational database, then one should try out a mutli-vauled system just to expand ones horizons as to how they work…


Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Sunday, April 30, 2006
 
 
>> Please explain this.  Are you advocating stored procedures instead of having SQL in the DAL? <<

I think what he's saying is that if you leave it up to the typical FE developer, you'll have SQL embedded in your HTML, and HTML stored in your database.

http://thedailywtf.com/forums/68993/ShowPost.aspx
example Send private email
Sunday, April 30, 2006
 
 
>> So that you need at least two developers any time you want to make a significant change or understand a complex problem?

If by "significant" you mean "requiring two developers" ... but many other changes can be performed by a specialist ... query tuning, GUI redesign, porting to a new front-end language etc.
David Aldridge Send private email
Sunday, April 30, 2006
 
 
Ok, two responses...

First the one about multiple developers. You bet.

I have met few, very few FE developers that are good at databases. T-SQL for one is completely different than say, C#. T-SQL (or any SQL for that matter) is set based, not loop based. If you don't know what that means, don't touch any of my DB's. 

This is where 99% of the cursors I've seen used come from.

But lets forget that one. Let's just say that you are the 'architect' and you don't do the SQL code, you only do the database design.

That's where we run into stuff like lack of primary, unique keys. Lack of foreign keys. Renaming foreign key columns. Incorrect indexing. Under normalization. Over normalization (Gender table, anyone?).

Here is my point. The database does very distinct things. Am I trying to build up DBA's to sound like the next Einstein or something? No. But maybe, just maybe the reason why the data access in your app is slow is not due to the database engine being garbage, maybe it's because it wasn't designed right to begin with.
D in PHX Send private email
Monday, May 01, 2006
 
 
This doesnt' mean however, that you need two developers to make changes. But often IMHO that is best.

Why?

Well because the database has to manage referential integrity and performance for a bunch of different data in a ton of different scenarios AND BE QUICK AND ACCURATE FOR ALL OF THEM.

So you're a FE dev. and you need need to add or update an object called FOO in the database. Great. That's all your code cares about. But the database does alot of other stuff. How often does FOO update? How many indexes are on table FOO. What about junction tables/ref. integrity?

Is there another set of tables with denormalized FOO for reporting? etc. etc.

As for putting SQL in the DAL, I don't do it. It is IMO a mess. Bad news.

I never like mixing languages. Stored procs should be in the DB, there are a small subset of DBA's that don't use stored procs...but don't pay attention to them.

To just wrap this up, basically there are companies that don't have dedicated database people. Most of them have FE's that don't really know databases. I've been there and it sucks.
D in PHX Send private email
Monday, May 01, 2006
 
 
As an aside, Ingres.Postgres..
was built on the class<=>table no ifs buts or maybes.

See Postgress documentation http://www.postgresql.org/
and google for Michael Stonebraker.
John Griffiths Send private email
Wednesday, May 03, 2006
 
 
That's a good point.

ORM is basically storing objects in a database yes?

Then my statement:

"In my experience doing FE development, the only time I would even consider the possibility of using a flat file was if I was guaranteed that I would never have another app needing to get to the data."

Would be extended to the object model.

The database is for storage. Storage of data. It can also be used for objects.

But by correctly designing and constraining a database you are placing rules and relationships on the data (or objects). An order always has a customer. A supervisor is a type of employee.

These rules, contraints and relationships make the data valuble. They give it meaning. Without them you might as well be tracking it in an Excel sheet, or even a flat file.

So to answer the question, if the objects that you are storing will only be used by one app it's a good idea, or if you are going to have multiple apps with IDENTICAL (or close) object models (which in this case is synonymous with the database model) then it could/would work.

Otherwise it is a big roll of the dice and if it doesn't work, the data doesn't mean anything.

-Don
D in PHX Send private email
Wednesday, May 03, 2006
 
 
"When all you have is a hammer, everything begins to look like a nail"

-Anonymous

Speaking from personal experience, being a former db-only developer, but now a pretty decent OO developer, part of the problem is 'specialists'.  E.g. folks who only know one thing, be that gui, the middle-tier or the database.  They don't have enough knowledge to make informed decisions about overall architecture.  GUI people want to put everything in the GUI.  Middle tier folks want everything in the middle tier, and DB guys want to put everything in the database.  Its simply because people choose to be in their 'comfort zone'. 

When folks get out of their comfort zone, they tend to just hack away until something works, then complain about the technologies they don't understand for being <insert favorite excuse here>. 

I think (just my opinion) generalized specialists are the way to go.  Folks who can cover the application front to back, with enough knowledge in all areas to make informed decisions, even if that decision is to find someone else who knows more than they do.  They are free to focus/improve on any area, as long as they retain that 'general' ability.  I find they decisions made by this kind of team are much more informed, and overall architecture is usually better because of it.
Another Anonymous Coward
Thursday, May 04, 2006
 
 
Like everything else in life, it all depends on what you need to optimize for. It's possible, I guess, to absolutely require the lack of overhead that a flat file would give you, but you have to give up so much useful infrastructure. Who wants to rewrite SELECT, INSERT, etc., hand code all the referential integrity, security, etc.?

From someone who's worked at the board level, it is just such luxury, why would you want to give it up?
Steve Hirsch Send private email
Tuesday, May 09, 2006
 
 
Most of the time these generalists are ok at everything...and good at nothing.

I've been on both sides of the fence, I've been a database designer, a dba, a C# winforms guy and an Asp.net web developer.

Just because you went to w3 schools and read the SQL primer does not mean you know something about databases, or even SQL for that matter.

I did a check on a table that was storing phone numbers.

The datatype was CHAR(42). No that is not a typo.

I have 29 customer phone numbers that are 42 characters long. It looks like the dataentry person fell asleep with their head on the keyboard...WTF?

That's not even the worst part, as I see over 12,000 customers that have 9 digit phone numbers. Excluding country code I need at least 10.. that is 12,000 people that we can't contact..due to a cr@ppy, non validated frontend blindly inserting data into a terribly designed table with no proper typing or constraints.

Are there generalists that can do both? Yeah, but they are d@mn hard to find.

The more I work with FE developers, the more I loathe them (in general).

For all the 'best practices' stuff out there, I cannot believe how little of it deals with databases and how much garbage an FE dev. can generate.

"I don't swim in your non-validating front end code, so don't sh!t in my database. Thank you."
D in PHX Send private email
Tuesday, May 16, 2006
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz