问题
I'm currently designing an application and I need to know how should be designed a constants parameter table. Also, I want to know how to use this table on the application.
For example: for a parameter sex (M or F) in a system, it should be in its own table or is better to have that parameter with others in a special table?. How can I "envelope" parameters in the subsequent layers (using a constants class with the parameters and their primary keys)?
I have heard about a special "DB pattern" or a common way to create a table such that its schema lets the development process to relay on this single parameter table. Do you know how's this called?
Also... could you recommend me any good bibliography on the issue?
回答1:
I've built and used many times what I call Parameter Enumeration Tables. The module is part of my ZXAF opensource framework.
Basic design is simple, you have a Parameters table that has a 1-many relationship with each table that needs a parametrised field. It looks something like this:
Expanding on this to provide a real example, where we are working with a users table that contains a status field. We index and link the field to the params table via a constraint as follows;
INDEX `FK_user_status` (`status`),
CONSTRAINT `FK_user_status` FOREIGN KEY (`status`) REFERENCES `params` (`id`)
ON UPDATE CASCADE ON DELETE CASCADE
NOTE: I'm using CASCADE here, there are times when you don't want to do this
This gives us the following schema;
The key concept of this is to allow the database to contain parameterised data that maintains referential integrity, and integrates with a data model within the code. The code is able to find out by querying the database how entities are related, and for example what the valid values for a specific field are.
Lastly I want to introduce and explain the concept of Parameters Tuples. This is another table that allows us to associate a pair of parameters (the Tuple) with a value. This a data neutral way in which we can extend PET provide the lookup and expected values. This is most suited to an extensible model where it is possible to add new enumerations, and yet we need to allow them to contain a value. It is often better to do this with *relationships*
I'm not in favour of enums in databases, but this is only my opinion and it may be something that you're happy with.
回答2:
I use a model similar in nature to what Richard Harrison posted.
Your code table can simplify matters if you have a handful of states specific to a subset of tables, but if these states aren't shared or needed by other parts of your database, then you risk making the code table even more confusing by storing everything in one place. This is a judgment call you'll have to make for yourself -- in my current application, I use one centralized Code table because the database is so small.
As for what you store here: I only keep records in the database of data that might change based on business needs. Some examples of this:
- Shipping destinations (you might only ship to a few states in the US, or a handful of countries in a particular region, etc.)
- Order status codes.
- Application roles.
If you anticipate changing the answer to a "sex" question from only M/F to Male, Female, Transgendered (or something like that, although strictly speaking we're now talking about gender rather than sex), or accommodating other genders, then I'd suggest including it in your database. Otherwise, for something that's as close to permanent as you can get, don't store it in the database.
回答3:
Most applications use an "enumeration". How you use these enums are wholly dependant on how the application is implemented.
Unless you are catering for more than just "M" and "F" genders, I'd put those two options in their own table.
You would "envelope" parameters in subsequent layers by writing a binding, which may or may not use some kind of marshalling. This is wholly dependant on how you implement the application.
回答4:
Maybe you are looking for what is called a Dimension table. This is related to SCDs. One of these could be your "single parameter table". With time you might find it's better to have multiple tables (sex, location, etc.)
来源：https://stackoverflow.com/questions/4445180/how-shoud-be-a-parameters-table-designed-and-used-on-businesses-and-gui-layers