Как можно представить наследование в базе данных?

Вы должны проверить, является ли minWidth null/undefined. также вы использовали два разных реквизита minWidth и btMinWidth!

getMinWidth = () => {
    if(this.props.minWidth) {
        console.warn('nob jockey');
        return {
            minWidth: this.props.minWidth
        };
    } else
        return {};
}

Вы также можете использовать его без функции:

<View style={[
    AppStyles.buttonRect,
    this.props.minWidth && {minWidth: this.props.minWidth},
]}>
208
задан Madhur Bhaiya 6 October 2019 в 21:33
поделиться

5 ответов

@Bill Karwin описывает три модели наследования в своей книге SQL Antipatterns, предлагая решения для антипаттерна SQL Entity-Attribute-Value. Вот краткий обзор:

Наследование одной таблицы (также известное как Наследование таблицы по иерархии):

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

+------+---------------------+----------+----------------+------------------+
| id   | date_issued         | type     | vehicle_reg_no | property_address |
+------+---------------------+----------+----------------+------------------+
|    1 | 2010-08-20 12:00:00 | MOTOR    | 01-A-04004     | NULL             |
|    2 | 2010-08-20 13:00:00 | MOTOR    | 02-B-01010     | NULL             |
|    3 | 2010-08-20 14:00:00 | PROPERTY | NULL           | Oxford Street    |
|    4 | 2010-08-20 15:00:00 | MOTOR    | 03-C-02020     | NULL             |
+------+---------------------+----------+----------------+------------------+

\------ COMMON FIELDS -------/          \----- SUBTYPE SPECIFIC FIELDS -----/

Сохранение простоты дизайна является плюсом, но основные проблемы с этим подходом заключаются в следующем:

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

  • База данных не сможет определить, какие атрибуты применяются, а какие нет, поскольку нет метаданных, определяющих, какие атрибуты принадлежат каким подтипам.

  • Вы также не можете применять NOT NULL к атрибутам подтипа, которые должны быть обязательными. Вам придется обрабатывать это в своем приложении, что в целом не идеально.

Наследование конкретной таблицы.

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

--// Table: policies_motor
+------+---------------------+----------------+
| id   | date_issued         | vehicle_reg_no |
+------+---------------------+----------------+
|    1 | 2010-08-20 12:00:00 | 01-A-04004     |
|    2 | 2010-08-20 13:00:00 | 02-B-01010     |
|    3 | 2010-08-20 15:00:00 | 03-C-02020     |
+------+---------------------+----------------+

--// Table: policies_property    
+------+---------------------+------------------+
| id   | date_issued         | property_address |
+------+---------------------+------------------+
|    1 | 2010-08-20 14:00:00 | Oxford Street    |   
+------+---------------------+------------------+

Этот дизайн в основном решит проблемы, выявленные для метода с одной таблицей:

  • Обязательные атрибуты теперь можно применять с помощью NOT NULL.

  • Добавление нового подтипа требует добавления новой таблицы вместо добавления столбцов в существующую.

  • Также отсутствует риск установки неподходящего атрибута для определенного подтипа, такого как поле vehicle_reg_no для политики свойства.

  • Нет необходимости в атрибуте type, как в методе одной таблицы. Тип теперь определяется метаданными: именем таблицы.

Однако эта модель также имеет несколько недостатков:

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

  • При определении таблиц вам придется повторять общие атрибуты для каждой таблицы подтипа. Это определенно не DRY.

  • Поиск всех политик, независимо от подтипа, усложняется и требует множества UNION.

Вот как вам придется запрашивать все политики независимо от типа:

SELECT     date_issued, other_common_fields, 'MOTOR' AS type
FROM       policies_motor
UNION ALL
SELECT     date_issued, other_common_fields, 'PROPERTY' AS type
FROM       policies_property;

Обратите внимание, что добавление новых подтипов потребует изменения приведенного выше запроса с дополнительным UNION ALL для каждого подтипа. Это может легко привести к ошибкам в вашем приложении, если вы забудете об этой операции.

Наследование таблицы классов (также известное как наследование таблицы по типу):

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

CREATE TABLE policies (
   policy_id          int,
   date_issued        datetime,

   -- // other common attributes ...
);

CREATE TABLE policy_motor (
    policy_id         int,
    vehicle_reg_no    varchar(20),

   -- // other attributes specific to motor insurance ...

   FOREIGN KEY (policy_id) REFERENCES policies (policy_id)
);

CREATE TABLE policy_property (
    policy_id         int,
    property_address  varchar(20),

   -- // other attributes specific to property insurance ...

   FOREIGN KEY (policy_id) REFERENCES policies (policy_id)
);

Это решение решает проблемы, выявленные в двух других схемах:

  • Обязательные атрибуты могут быть принудительно установлены с помощью NOT NULL.

  • Добавление нового подтипа требует добавления новой таблицы вместо добавления столбцов в существующую.

  • Нет риска того, что для определенного подтипа будет установлен неподходящий атрибут.

  • Атрибут type не нужен.

  • Теперь общие атрибуты больше не смешиваются со специфическими атрибутами подтипа.

  • Наконец-то мы можем остаться СУХИМИ. Нет необходимости повторять общие атрибуты для каждой таблицы подтипа при создании таблиц.

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

  • Поиск всех политик, независимо от подтипа, теперь становится очень простым: не требуется UNION — достаточно SELECT * FROM политик.

В большинстве случаев я считаю, что подход с использованием таблицы классов является наиболее подходящим.


Названия этих трех моделей взяты из книги Мартина Фаулера Шаблоны архитектуры корпоративных приложений.

397
ответ дан 23 November 2019 в 04:41
поделиться

С другой стороны, рассмотрите использование документных баз данных (таких как MongoDB), которые исходно поддерживают богатые структуры данных и вложение.

0
ответ дан 23 November 2019 в 04:41
поделиться

С предоставленной информацией я бы смоделировал базу данных следующим образом:

POLICIES

  • POLICY_ID (первичный ключ)

LIABILITIES

  • LIABILITY_ID (первичный ключ)
  • POLICY_ID (внешний ключ)

PROPERTIES

  • PROPERTY_ID (первичный ключ)
  • POLICY_ID (внешний ключ)

... и так далее, потому что я ожидаю, что будут разные атрибуты, связанные с каждый раздел политики. В противном случае может быть одна таблица SECTIONS и в дополнение к policy_id будет section_type_code...

В любом случае, это позволит вам поддерживать необязательные разделы для каждой политики...

Я не понимаю, что вы находите неудовлетворительным в этом подходе - это то, как вы храните данные, сохраняя ссылочную целостность и не дублируя данные. Термин "нормализованный"...

Поскольку SQL основан на SET, он довольно чужд концепциям процедурного/OO программирования и требует кода для перехода из одной области в другую. ORM часто рассматривают, но они плохо работают в больших объемах сложных систем.

9
ответ дан 23 November 2019 в 04:41
поделиться

Я склоняюсь к методу № 1 (унифицированная таблица разделов) для эффективного извлечения целых политик со всеми их разделами (что, как я предполагаю, будет делать ваша система).

Кроме того, я не знаю, какую версию SQL Server вы используете, но в версии 2008+ Разреженные столбцы помогают оптимизировать производительность в ситуациях, когда многие значения в столбце будут NULL.

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

0
ответ дан 23 November 2019 в 04:41
поделиться
-2
ответ дан 23 November 2019 в 04:41
поделиться
Другие вопросы по тегам:

Похожие вопросы: