Каким будет таблица параметров, спроектированная и используемая на бизнес-уровнях и графических интерфейсах?

Question

Я сейчас разрабатываю приложение, и мне нужно знать, как следует составлять таблицу параметров констант. Кроме того, я хочу знать, как использовать эту таблицу в приложении. Например: для параметра sex (M или F) в системе он должен быть в собственной таблице или лучше иметь этот параметр с другими в специальной таблице ?. Как я могу «огибать» параметры в последующих слоях (используя класс констант с параметрами и их первичными ключами)?

Я слышал о специальном «шаблоне базы данных» или об общем способе создания таблицы, так что ее схема позволяет процессу разработки ретранслировать эту таблицу одиночных параметров. Вы знаете, как это называется?

Также ... вы могли бы порекомендовать мне любую хорошую библиографию по этому вопросу?

Answer 1

Я построил и использовал много раз, что я называю Parameter Enumeration Tables. module является частью моего ZXAF opensource framework.

Базовый дизайн прост, у вас есть таблица Parameters, которая имеет отношение 1-много к каждой таблице, которая нуждается в параметризованном поле. Это выглядит примерно так:

Расширяющихся на этом, чтобы обеспечить реальный пример, где мы работаем с users таблицы, содержащей status поля. Мы индексируем и связываем поле с таблицей params через ограничение следующим образом;

INDEX `FK_user_status` (`status`), 
CONSTRAINT `FK_user_status` FOREIGN KEY (`status`) REFERENCES `params` (`id`) 
      ON UPDATE CASCADE ON DELETE CASCADE 

Примечание: Я использую CASCADE здесь, бывают случаи, когда вы не хотите, чтобы это сделать

Это дает нам следующую схему;

Ключевое понятием этого является позволить базе данных содержат параметризованные данные, которая поддерживает ссылочную целостность, и интегрируется с моделью данных в коде. Код можно узнать, запросив базу данных, как связаны сущности, и, например, какие допустимые значения для определенного поля.

Наконец я хочу представить и объяснить концепцию Tuples параметров. Это еще одна таблица, которая позволяет связать пару параметров (Tuple) со значением. Это нейтральный для данных способ, которым мы можем расширить PET, обеспечивает поиск и ожидаемые значения.Это наиболее подходит для расширяемой модели, где можно добавлять новые перечисления, и все же мы должны позволить им содержать значение. Часто лучше сделать это с * отношений *

Я не favour of enums in databases, но это только мое мнение, и это может быть то, что вы будете довольны.

Answer 2

В большинстве приложений используется «перечисление». Как вы используете эти перечисления, полностью зависит от того, как приложение реализовано.

Если вы не обслуживаете больше, чем просто «M» и «F», я бы поставил эти два варианта в свой собственный стол.

Вы будете «огибать» параметры в последующих слоях, написав привязку, которая может или не может использовать какой-либо маршаллинг. Это полностью зависит от того, как вы реализуете приложение.

Answer 3

Я использую модель, похожую по характеру на то, что написал Ричард Харрисон.

Ваша таблица кодов может упростить ситуацию, если у вас есть несколько состояний, специфичных для подмножества таблиц, но если эти состояния не разделены или не нужны другими частями вашей базы данных, тогда вы рискуете сделать таблицу кода даже более запутанным, сохраняя все в одном месте. Это решение, которое вам нужно будет сделать для себя - в моем текущем приложении я использую одну централизованную таблицу кодов, потому что база данных настолько мала.

Что касается того, что вы храните здесь: я сохраняю только записи в базе данных, которые могут измениться в зависимости от потребностей бизнеса. Некоторые примеры этого:

• назначение доставки (вы можете отправить только несколько государств в США или несколько стран в конкретном регионе и т.д.)
• коды статуса заказа.
• Роли приложения.

Если вы ожидаете изменить ответ на вопрос «секс» только от M/F к Male, Female, Transgendered (или что-то в этом роде, хотя, строго говоря, теперь мы говорим о гендерном, а не о сексе) или размещения других полов, тогда я бы предложил включить его в вашу базу данных. В противном случае, для того, что можно как можно ближе к постоянному, не храните его в базе данных.

Answer 4

Возможно, вы ищете таблицу Dimension. Это связано с SCD. Одна из них может быть вашей «таблицей с одним параметром». Со временем вы можете обнаружить, что лучше иметь несколько таблиц (пол, местоположение и т. Д.).