Good place to look for example Database Designs - Best practices [closed]

Question

I have been given the task to design a database to store a lot of information for our company. Because the task is rather big and contains multiple modules where users should be able to do stuff, I'm worried about designing a good data model for this. I just don't want to end up with a badly designed database.

I want to have some decent examples of database structures for contracts / billing / orders etc to combine those in one nice relational database. Are there any resources out there that can help me with some examples regarding this?

Answer 1

Barry Williams has published a library of about six hundred data models for all sorts of applications. Almost certainly it will give you a "starter for ten" for all your subsystems. Access to this library is free so check it out.

It sounds like this is a big "enterprise-y" application your organisation wants, and you seem to be a bit of a beginner with databases. If at all possible you should start with a single sub-system - say, Orders - and get that working. Not just the database tables build but some skeleton front-end for it. Once that is good enough add another, related sub-system such as Billing. You don't want to end up with a sprawling monster.

Also make sure you have a decent data modelling tool. SQL Power Architect is nice enough for a free tool.

Answer 2

Before you start read up on normalization until you have no questions about it at all. If you only did this in school, you probably don't know enough about it to design yet.

Gather your requirements for each module carefully. You need to know:

Business rules (which are specific to applications and which must be enforced in the database because they must be enforced on all records no matter the source),

Are there legal or regulatory concerns (HIPAA for instance or Sarbanes-Oxley requirements) security (does data need to be encrypted?)

What data do you need to store and why (is this data available anywhere else)

Which pieces of data will only have one row of data and which will need to have multiple rows?

How do you intend to enforce uniqueness of the the row in each table? Do you have a natural key or do you need a surrogate key (suggest a surrogate key in almost all cases)?

Do you need replication?

Do you need auditing?

How is the data going to be entered into the database? Will it come from the application one record at a time (or even from multiple applications)or will some of it come from bulk inserts from an ETL tool or from another database.

Do you need to know who entered the record and when (highly likely this will be necessary in an enterprise system.

What kind of lookup tables will you need? Data entry is much more accurate when you can use lookup tables and restrict the users to the values.

What kind of data validation do you need?

Roughly how many records will the system have? You need to have an idea to know how big to create your test data.

How are you going to query the data? Will you be using stored procs or an ORM or dynamic queries?

Some very basic things to remember in your design. Choose the right data type for your data. Do not store dates or numbers you intend to do math on in string fields. Do store numbers that are not candidates for math (part numbers, zip codes, phone numbers, etc) as string data as you may need leading zeros. Do not store more than one piece of information in a field. So no comma-concatenated lists (these indicate the need for a related table) and while you are at it if you find yourself doing something like phone1, phone2, phone 3, stop right away and design a related table. Do use foreign keys for data integrity purposes.

All the way through your design consider data integrity. Data that has no integrity is meaningless and useless. Do design for performance, this is critical in database design and is NOT premature optimization. Database do not refactor easily, so it is important to get the most critical parts of the performance equation right the first time. In fact all databases need to be designed for data integrity, performance and security.

Do not be afraid to have multiple joins, properly indexed these will perform just fine. Do not try to put everything into an entity value type table. Use these as sparingly as possible. Try to learn to think in terms of handling sets of data, it will help your design. Databases are optimized to do things in sets.

There's more but this is enough to start digesting.