Worst database design I've ever seen.
-
:omg: No primary key or index on every table. No view, No stored procedure, No trigger. :doh: I'm not sure whether it even fit for 1st Norm. This database is used by our company's previous accounting system. I've heard a colleague told me that they have to restart the system once (or more) per day.
-
:omg: No primary key or index on every table. No view, No stored procedure, No trigger. :doh: I'm not sure whether it even fit for 1st Norm. This database is used by our company's previous accounting system. I've heard a colleague told me that they have to restart the system once (or more) per day.
Sounds like a third-party product we used to use. I suspect that the application read everything into memory and then just worked with it there. X|
-
Sounds like a third-party product we used to use. I suspect that the application read everything into memory and then just worked with it there. X|
Sounds like SAP to me. Have you seen the database? Talk about a coding WTF....
Deja View - the feeling that you've seen this post before.
-
:omg: No primary key or index on every table. No view, No stored procedure, No trigger. :doh: I'm not sure whether it even fit for 1st Norm. This database is used by our company's previous accounting system. I've heard a colleague told me that they have to restart the system once (or more) per day.
A good excuse I heard for that nonsense is that " That is good for preformance" !! RTFM = Read the F***ing manual.
-
:omg: No primary key or index on every table. No view, No stored procedure, No trigger. :doh: I'm not sure whether it even fit for 1st Norm. This database is used by our company's previous accounting system. I've heard a colleague told me that they have to restart the system once (or more) per day.
cartergu wrote:
No primary key or index on every table.
:wtf:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
-
:omg: No primary key or index on every table. No view, No stored procedure, No trigger. :doh: I'm not sure whether it even fit for 1st Norm. This database is used by our company's previous accounting system. I've heard a colleague told me that they have to restart the system once (or more) per day.
-
Sounds like a third-party product we used to use. I suspect that the application read everything into memory and then just worked with it there. X|
I once had to work with a database like that. It was just a huge number of tables, as described, but with the added bonus of *no* foreign key relationships. Evidently, all foreign keys and referential integrity was handled by the application.
-
I once had to work with a database like that. It was just a huge number of tables, as described, but with the added bonus of *no* foreign key relationships. Evidently, all foreign keys and referential integrity was handled by the application.
There are still people who argue that there should be no referential integrity on production databases.
-
I once had to work with a database like that. It was just a huge number of tables, as described, but with the added bonus of *no* foreign key relationships. Evidently, all foreign keys and referential integrity was handled by the application.
I have actually created databases using this model and while FKs are great they should not be used to test the integrity of the data. Wait till you see an app where the developer attempts to save a record and traps the FK exception. Talk about programming by error!
Never underestimate the power of human stupidity RAH
-
There are still people who argue that there should be no referential integrity on production databases.
PIEBALDconsult wrote:
There are still people who argue that there should be no referential integrity on production databases
That tends to be my preference, I prefer to code the referential integrity through the application code rather than embed it in the database. I won't give the reasons why this can be a very good idea as there will be plenty of counter reasons as to why it is a very bad idea. :sigh:
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
-
PIEBALDconsult wrote:
There are still people who argue that there should be no referential integrity on production databases
That tends to be my preference, I prefer to code the referential integrity through the application code rather than embed it in the database. I won't give the reasons why this can be a very good idea as there will be plenty of counter reasons as to why it is a very bad idea. :sigh:
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
No referential integrity sometime acceptable. But if you don't have key or index on every table, it will slow down query significantly. (For some complicated join query, it will be 10 to 100 times slower than the one with indexes). :confused:Can you imagine you have to wait 20 minutes only to print a invoice? (And during this time, all the other people almost can't do anything) :omg: If you design database like this, I would really hope I'll never cooperate with you.
-
No referential integrity sometime acceptable. But if you don't have key or index on every table, it will slow down query significantly. (For some complicated join query, it will be 10 to 100 times slower than the one with indexes). :confused:Can you imagine you have to wait 20 minutes only to print a invoice? (And during this time, all the other people almost can't do anything) :omg: If you design database like this, I would really hope I'll never cooperate with you.
Indexes - pwah! Real men use table scans in their queries - indexes are for cheats :rolleyes: :laugh:
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)