设计要在N层应用程序中使用的数据库

Question

I am working on an N-tier application using .NET (C#, SQL Server). I started by designing the database because I believe starting from bottom would a good idea. Now I need your suggestions in building the database to be very flexible. Knowing that the application is intended to built as a group of plug-ins.

The application is a remote control app for many different hardware devices (Cars, Engines, etc) Here is a fragment of the database tables.

1. Devices Table
2. Personnel Table
3. Users Table
4. Roles Table

As you can see the devices table is a table to represent the devices we are controlling and since each each device may have more or less properties than others I want to link each device to its properties which might be in another table in way that is as elegant as possible. The personnel table is for the people responsible for the device for example: Car drivers (there might be more than one driver for each car), Engine operator, etc.

Users are the application users as you can see I have separated the users and roles into two different tables.

What I am looking for is a way to link the devices to their properties. Plus, In the application each device is an instance of an attachable device. Meaning that I can attach a device called say: SIM card to a device called Vehicle. Moreover, are there any design patterns regarding this subject?

Thanks in advance, and please pardon me if I am not clear.

Answer 1

The real design decision here is around your Device and Property tables. The others are pretty standard.

For a Device to be optionally associated with one or many properties, then all you really need is a nullable foreign key in your Property table. But this raises one very important question: Is it necessary for certain devices to have a very specific set of properties? Will your application be expecting a 'Model' property for your 'Car' device? How do we ensure database integrity with this kind of design?

You can do this through database-defined constraints. But how should you know that a 'Car' device requires a 'Model' property? Perhaps you need a template definition for each device: DeviceType and PropertyType tables. This way your constraint will always know what properties are expected when you are updating/inserting a record. Also, this will make it easy to work with the data in your application.

Answer 2

Depending on how you are going to be handling your data layer this database design may be a moot point. If you were to use EntityFramework with a code first approach you can create your logical entities using that and generate the database from your models.

Most ORM based solutions provide some way to create a database from your objects relationship, but although you can quickly and easily get a database up and running which will do EXACTLY what you NEED, if you want to start playing with the schema you may run into troubles, although you can do quite alot of inferring to help it make the database behind the scenes the way you want it.

If this is a greenfield project and you dont need to accommodate any legacy database system I would stop worrying about your database for the moment and just get to writing your logical models and defining their relationships, and let the data storage concerns handle themselves.

Answer 3

There is no ideal database design for anything. It can quickly change according to the information you are manipulating.

One simple approach is to list all the classes in your design and then break those classes to the lowest level possible without any repeating data.

Even each device has various properties, you can classify the devices into their respective group and a group will have mostly similar properties. You can build a property table including all the properties for that group. As you said, you can connect them in a different table with deviceID and propertyID. Same thing goes for a person and device. You can break the person table into smaller pieces depending on the attributes you have.

If numerous tables form a cluster in terms of data extrection, you can consider a star schema for your solution with a fact table (real numbers) in the center and the associated data around it.

Good Luck!