Дизайн базы данных - пустые поля

В настоящее время я обсуждаю проблему с моей командой разработчиков. Они считают, что пустые поля - плохие новости. Например, если у нас есть таблица сведений о клиентах, в которой хранятся данные для клиентов из разных стран, и каждая страна имеет немного другую конфигурацию адреса - плюс 1-2 дополнительных поля, например. Французская информация о клиенте также может содержать сведения о кодах ввода, а также пол/уровень плюс поля заголовка (madamme и т.д.). У Южной Африки будет номер безопасности. И так далее.

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

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

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

Другой вариант - это отдельная таблица мини-EAV, в которой хранятся дополнительные данные с полями parent_id, key, val. Или для сериализации дополнительных данных в столбец extra_data в главной таблице customer_data.

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

Итак, мой вопрос конкретно: -

Если у вас есть небольшие отклонения в данных для каждой записи (например, 1-2 разных поля), то что лучше всего продолжить?

Ответ 1

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

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

Ответ 2

Существует определенно школа мысли, которая содержит, что поля NULL плохие, в и из них. Реляционная теория требует, чтобы базы данных состояли из фактов, а NULL - это отсутствие факта. Таким образом, в базе данных с жесткой конструкцией не было бы нулевых столбцов.

Ваш коллега предлагает что-то, что находится на пути к 6-й нормальной форме, где все таблицы состоят из первичного ключа и не более одного столбца. Только в такой схеме у нас не было бы таблиц, называемых customer_info_fr. Это не нормализовалось. Многие страны могут включать в него ENTRY_CODE. Поэтому нам понадобится address_entry_codes и address_floor_numbers. Не говоря уже о address_building_number и address_building_name, поскольку некоторые места идентифицируются по числу и другим по имени.

Это абсолютно точный и правдивый, как логический дизайн. Увы, с физической точки зрения, это сосать! Простейший запрос - select * from addresses - становится объединением с несколькими столами, а внешние соединения на этом. Неудачные столбцы - это способ примирить уродливый дизайн с твердой истиной, "вы не можете нарушить законы физики". Nullable columns позволяют объединять непересекающиеся наборы данных в одну таблицу, хотя и ценой обработки нулей (они могут влиять на поиск данных, использование индекса, математику и т.д.).

Ответ 3

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

Для такого рода данных вы, вероятно, используете VARCHAR или какой-то столбец TEXT, которые являются полями переменной длины в базе данных. Неважно, если ваше поле заполнено данными или пустое, вы по-прежнему будете нести накладные расходы столбца переменной длины (что не стоит беспокоиться в обычных обстоятельствах). Таким образом, нет разницы с РСУБД.

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

Ответ 4

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

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

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

Ответ 5

То, что для полей с нулевым значением: "Данные недоступны/применимы".

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