Выбор структуры базы данных для мастера ценообразования

Question

Вариант А

Мы работаем над небольшим проектом, который требует мастера ценообразования для пользовательских таблиц. (Да, настоящие пользовательские столы - те, за которыми вы едите. Отсюда я буду называть их кухонными столами, чтобы мы не путались) Я придумал модель, в которой каждая часть кухонного стола была таблицей базы данных. Итак, база данных выглядела так:

TableLineItem
-------------
ID
TableSizeID
TableEdgeWoodID
TableBaseID
Quantity

TableEdgeWoodID
---------------
ID
Name
MaterialUnitCost
LaborSetupHours
LaborWorkHours

Каждая часть должна иметь возможность рассчитать свою цену. Большинство расчетов очень похожи. Мне понравилась эта структура, потому что я могу перетащить ее прямо в конструктор linq-to-sql и сгенерировать все мои классы. (Меньше написания кода означает меньше обслуживания ...) Затем я реализую интерфейс вычисления стоимости, который просто принимает размер таблицы. Я написал несколько тестов, и это хорошо работает. Я также добавил таблицу для фильтрации деталей в пользовательском интерфейсе на основе предыдущих выборов. (Вы не можете иметь конкретную древесину с определенной отделкой.) В модели есть еще одно исключение, и у меня они жестко закодированы. Эта модель очень жесткая, и изменение требований приведет к изменению модели данных. (Например, если на всех столах вдруг понадобятся зонтики.)

Вариант B:

После различных встреч с моими коллегами (что, вероятно, занимало больше времени, чем следовало бы, учитывая размер этого проекта), мои коллеги решили, что они предпочтут более общий подход. Примерно так:

Spec
----
SpecID
SpecTypeID
TableType_LookupID
Name
MaterialUnitCost
LaborSetupHours
LaborWorkHours

SpecType 
--------
SpecTypeID
ParentSpecType_SpecTypeID
IsCustomerOption
IsRequiredCustomerOption

и т.д ...

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

Вопросы:

1. Какую структуру базы данных вы предпочитаете? Не стесняйтесь предлагать свои собственные.
2. Что можно считать лучшей практикой? Если у вас есть несколько похожих таблиц базы данных, вы создаете 1 таблицу базы данных со столбцом типа или несколько отдельных таблиц? Я подозреваю, что ответ начинается с "Это зависит ..."
3. Какова будет предполагаемая разница во времени в двух подходах (1 неделя, 1 день, 150% больше и т. Д.)

Заранее спасибо. Дайте мне знать, если у вас есть какие-либо вопросы, чтобы я мог обновить это.

Answer 1

У меня нет времени для полного ответа прямо сейчас, но я выкину это:

• Обычно плохая идея проектировать базу данных на основе инструмента разработки, который вы используете для кодирования против нее.
• Вы хотите быть универсальным до точки . Таблицы в базе данных должны представлять что-то, и это можно сделать слишком общим. Например, таблица под названием «Вещи», вероятно, слишком общая.
• Может быть возможно создать ограничения, которые выходят за рамки того, что вы ожидаете. Ваш пример "столовой базы" с "столовой древесиной" не имел для меня смысла, но если вы сможете расширить конкретный пример, кто-то может помочь с этим.
• Наконец, если это небольшое приложение для одного магазина, то ваш дизайн окажет гораздо меньшее влияние на результат проекта, чем если бы вы разрабатывали приложение, которое будет интенсивно использоваться и постоянно изменяться. Это восходит к «слишком общим» комментариям выше. Можно перестроить систему, когда ее использование будет минимальным и четко определенным. Я надеюсь, что это имеет смысл.

Учитывая ваш комментарий ниже об основах и лесах таблиц, вы можете создать таблицу с именем TableAttributes (или что-то подобное), и каждый возможный параметр будет иметь определенный тип атрибута таблицы. Затем вы можете принудительно установить, что любая данная опция используется только для атрибута, к которому она применяется, через внешние ключи.

Answer 2

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

Answer 3

Вариант Б ..

Общее, как правило, лучше, чем конкретное. Программное обеспечение уже обречено на провал или достигает своей емкости благодаря своей конструкции только для определенного набора задач. Если вы создаете что-то общее, оно будет меньше ломаться, если абстрагироваться от реалистического анализа того, куда он может идти. Пока вы держитесь подальше от чрезмерной абстракции и недостаточной абстракции, это, вероятно, самое приятное место.

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

Answer 4

Вот что мне скажет мой опыт:

1. Какую структуру базы данных вы предпочитаете? Без сомнения, я бы выбрал первый подход. Пойдите для самой простой установки, которая могла бы работать. Если вы добавляете сложность, всегда спрашивайте себя, какую ценность это будет иметь для клиента?
2. Что будет считаться наилучшей практикой? Это действительно зависит, среди прочего, от размера проекта и ожидаемой скорости изменений. Как правило, общие таблицы того стоят, когда вы ожидаете, что клиент будет добавлять новые типы. Например, если ваш клиент хочет добавить новую «цветную» сущность в таблицу, вам понадобятся общие таблицы. Вы не можете заранее предсказать, что они добавят.
3. Какова будет предполагаемая разница во времени в двух подходах? Не зная вашего бизнеса, навыков и среды, невозможно дать достоверную оценку . Подход, который вы уверены в кодировании, займет меньше всего времени. Здесь я думаю, что подход № 1 может быть в 5х-50х раз быстрее. Общие таблицы сложны как на базе данных, так и на стороне клиента.

Answer 5

Существует тенденция к чрезмерному абстрагированию при проектировании схемы базы данных, поскольку стоимость изменений может быть высокой. Сам я люблю названия таблиц, которые достаточно описательны. Я часто приравниваю дизайн схемы к дизайну ОО. Например, вы бы обычно не создавали класс с именем Thing, вы, вероятно, назвали бы его Product, Furniture, Item, то, что относится к вашему бизнесу.

В предоставленной вами схеме есть сочетание абстрактного (спецификации) и конкретного (TableType_LookupID). Я хотел бы выровнять уровень абстракции, поэтому используйте такие объекты, как:

ProductGroup (for the case where you have a product that is a collection of other products)
Product
ProductType
ProductDetail 
ProductDetailType
etc.