在bussiness和GUI层上设计和使用的参数表如何？ [英] How shoud be a parameters table designed and used on bussinesses and GUI layers?

问题描述

我正在设计一个应用程序，我需要知道如何设计一个常量参数表。另外，我想知道如何在应用程序中使用这个表。
例如：对于系统中的一个参数性别（M或F），它应该在自己的表中，或者最好在特殊表中与其他参数一起使用该参数。我如何在后续的层中使用参数（使用带有参数和主键的常量类）？

我听说过一个特殊的DB模式或者创建表的常见方式，使得其模式允许开发过程在该单个参数表上进行中继。你知道这是怎么回事？

另外...你可以在这个问题上推荐我任何好的参考书目吗？

解决方案

我已经建立并使用了很多次我所说的 。这是另一个表，允许我们将一对参数（元组）与一个值相关联。这是一个数据中性的方式，我们可以扩展 PET 提供查找和预期值。这最适合于可以添加新枚举的可扩展模型，但是我们需要允许它们包含一个值。

我不在赞成数据库中的枚举，但这只是我的意见，它可能是你感到高兴的东西。 / p>

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?

解决方案

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.

这篇关于在bussiness和GUI层上设计和使用的参数表如何？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！