Stop the madness...
-
Ok...well I can't post the screenshot...or tell why, but here it is... While learning an inherited database schema for a suite of apps that we are taking over, I found a database diagram called Unrelated Tables containing sure enough, 22 unrelated tables. I had to stop there. X|
-
Ok...well I can't post the screenshot...or tell why, but here it is... While learning an inherited database schema for a suite of apps that we are taking over, I found a database diagram called Unrelated Tables containing sure enough, 22 unrelated tables. I had to stop there. X|
while not the best practice I have several sets of unreleated tables, simply because there is no real way to relate them to anything, and they have over 400 million rows of data between them, and some other groups that are transactional and only related to each other for application performance reasons. I can search the 400 million+ rows in less than a second(on a 10 character compare no less, no or very few int compares), the old db server could do it in under a second and it was 4 or 5 years old.
Please remember to rate helpful or unhelpful answers, it lets us and people reading the forums know if our answers are any good.
-
Ok...well I can't post the screenshot...or tell why, but here it is... While learning an inherited database schema for a suite of apps that we are taking over, I found a database diagram called Unrelated Tables containing sure enough, 22 unrelated tables. I had to stop there. X|
These tables might have their merit. For example for storing data that really does not relate to anything else but is still worth storing in the database.
-
while not the best practice I have several sets of unreleated tables, simply because there is no real way to relate them to anything, and they have over 400 million rows of data between them, and some other groups that are transactional and only related to each other for application performance reasons. I can search the 400 million+ rows in less than a second(on a 10 character compare no less, no or very few int compares), the old db server could do it in under a second and it was 4 or 5 years old.
Please remember to rate helpful or unhelpful answers, it lets us and people reading the forums know if our answers are any good.
I should have been more specific...in all the tables, there are a few records to a few thousand. They do relate to each other, but have no relationships setup.
-
These tables might have their merit. For example for storing data that really does not relate to anything else but is still worth storing in the database.
I wish it were the case. Other response
-
I should have been more specific...in all the tables, there are a few records to a few thousand. They do relate to each other, but have no relationships setup.
thats better than a product we found...dozens if not hundreds of FK's many circuliar, and several per table(read 2 or 3 FK's to table b, which has several back to table a, along with various others..some are circular and involve 3 to 4 tables in a big loop), all on character keys. doing anything in that DB takes forever. importing 20k rows took 24 or so hours(run time), because of all the extra data that had to be created and integrity checks the server had to make.
Please remember to rate helpful or unhelpful answers, it lets us and people reading the forums know if our answers are any good.
-
I wish it were the case. Other response
At least better than using strings which are created by adding several different infos as primary keys. Especially when a certain combination of these infos can appear multiple times and you need to add new rows in tables, not because they contain new data, but only because the primary key of a different table would be the same as it uses the same combination of infos. Or using columns with non-atomic values as lists separated by commas (I can tell you, getting all entries from that list is a pain)...
-
At least better than using strings which are created by adding several different infos as primary keys. Especially when a certain combination of these infos can appear multiple times and you need to add new rows in tables, not because they contain new data, but only because the primary key of a different table would be the same as it uses the same combination of infos. Or using columns with non-atomic values as lists separated by commas (I can tell you, getting all entries from that list is a pain)...
Sometimes using compound string keys is the only way to maintain data between multiple systems / instances where there is no shared system key (and no reason to force such a situation). That said, you would hope the individual elements which were used to generate the keys are available as individual columns also to give good performance for queries...
AJ