Помощь в разработке таблиц SQL

Question

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

Я создал таблицу местоположений master

-----------------------------
| LocationID | LocationName |
-----------------------------
|     1      |     Reno     |
-----------------------------
|     2      |  San Diego   |
-----------------------------

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

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

WebTool1 settings table
    ------------------------------------------------------
    | LocationID | HasAirConditioning|  HasSecurityGuard |
    ------------------------------------------------------
    |     1      |     TRUE          |       TRUE        |
    ------------------------------------------------------
    |     2      |     FALSE         |      TRUE         |
    ------------------------------------------------------

WebTool2 settings table
    -------------------------------------------------------
    | LocationID | ServerName   |  RequiresDriveMapping   |
    -------------------------------------------------------
    |     1      | DELLSERVER1  |       TRUE              |
    -------------------------------------------------------
    |     2      |  HPSERVER3   |      FALSE              |
    -------------------------------------------------------

Это хорошая стратегия?Если нет, то почему?

Answer 1

Я думаю, это идеальная стратегия.

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

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

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

Мне лично нравится, что моя структура базы данных отражает бизнес. Он чувствует себя более самодокументирующимся ИМО.

Answer 2

Насколько большими будут эти таблицы? Если таблицы будут содержать 1000 или менее строк, нет проблем. Но если оно составляет 100 КБ или более, вам нужно подумать, как вы собираетесь запрашивать эти таблицы, потому что объединения таблиц могут стать медленными.

Например, вы хотите отобразить все строки с SERVERNAME = HPSERVER3 и LOCATIONNAME = RENO, а также таблицы транзакций, если HPSERVER3 имеет много строк, а RENO также имеет много строк, возможно, планировщик запросов выполнит вложенное соединение, и запрос будет медленным. Индекс поможет, но его сложнее настроить, чем объединить все столбцы в одну таблицу.

Answer 3

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

Разделение полей с помощью некоторой внутренней логической группировки вместо приложения может также иметь больше смысла с точки зрения чистой схемы. Например LocationItInfrastructure и LocationBuildingOperations или что-то подобное, а не LocationApp1 и LocaationApp2.

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