Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
 Posted - 2005-05-12 : 21:29:24
|
| Has anyone ever come across an organization that has attempted to create standard relational database designs? For example, one that might include general ledger, accounts payable, accounts receivable, order entry and processing, inventory, and other modules that a retail organization might need.I am not looking for a specific solution. I just know that modeling the data for an organization is usually a huge job, and I am wondering if anyone has ever attempted to take on creating generic models that you could just drop into a design as a starting point. I am not talking about simplistic designs, but real world, complete models that have a lot of effort and thought behind them.I see a lot of different database designs from customers, vendors, etc. and I am amazed at how poor most of them are. I see the same data modeling mistakes made over and over, and know that for most of them it is far to late to fix the design.If there was a library of generic models available, I think it would be a huge help even to advanced designers. There is not much sense in designing a wheel every time one is needed. CODO ERGO SUM |
|
|
byrmol
Shed Building SQL Farmer
1591 Posts |
Posted - 2005-05-12 : 21:41:13
|
| That would be your/mine code library Michael.I have thought about this before... Setting up the "OSO".. The Open Schema Organisation.The first schema was going to be a game of chess...To be frank, a huge chunk of my work is fixing the crap that other people have started.. Not very exciting, but it puts lobster on the table...DavidMA front-end is something that tries to violate a back-end. |
 |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2005-05-12 : 22:01:45
|
| I've gotten the same impression you both have, there's a lot of poorly designed stuff that tries to do everything but none of it well. I think that might be why there isn't such a general library of schemas available, it's probably not practical enough to be used. I know I've tried and seen others try to put accounting functions into billing or other systems, and either gave up or wish they'd never started because of all the grief it causes. I would say that's why people end up buying Great Plains or Siebel or some other huge package and end up using half of it or less. IMHO it's often not worth trying to make them all work together anyway.BTW, I did a data conversion for a similar product, a pretty complete package offering everything you've described and a lot more.WORST. SCHEMA. EVER.I'm not kidding when I say I've (almost completely) reversed my opinion on identity primary keys because of this software. Many, many, MANY tables with 4, 5, 6 column primary keys, and every one of them clustered the wrong way. All of the trigger code was copied from Oracle and Gupta SQL. Cursors EVERYWHERE. They obviously designed this to work at the lowest common denominator possible. It's sad in a way, because they actually put in foreign keys, constraints, all the good and proper design stuff, they just went waaaaaaaaaaaaaay overboard with it.All I can say is it's a good thing they provide tools to run reports and migrate data with it, because trying to do it on your own is utterly impossible. |
|
|
|
|
|
|
|
|
Database Design Libraries?