Как помогает связь полей между таблицами в запросах sql, если вариантов в столбце не так много?
Я знаю что с помощью связи по полю можно обновлять или удалять данные из связанных таблиц. Такой способ я применял когда делал структуру таблицу пользователей, которая зависела от сотрудников организации. Когда сотрудник организации увольнялся, то он автоматически удалялся из таблицы пользователей. Но меня интересуют другая сторона. Допустим есть таблица peoples в которые все популярные данные фио, пол, год рождения, СНИЛС, паспорт, полис, а так же такие данные как группа инвалидности, номер телефона, электронная почта. Допустим полей может быть намного больше и данные в них могут быть, а могут и не быть, как с тем же номером телефона, электронной почтой или группой инвалидности. Есть ли смысл плодить отдельные таблицы например phones и делать связь по id peoples? В чём преимущество и недостатки хранения всех данных в одной таблице, ведь например при выборке телефонов, в любом случае их нужно будет объединять в строку с разделителями(например ;)или массив. Тогда можно так же записывать человеку телефоны через ";" и не париться со связями и не создавать дополнительных таблиц.
Я прекрасно понимаю когда идёт связь клиент-> заказ и прочие, когда вешается связь на огромное количество строк данных принадлежащих к одному клиенту, но как поступить если у поля может быть только небольшой список значений, который прекрасно может поместиться в том же поле varchar?
Ответы (1 шт):
Я согласен с коллегой, что нужно разобраться с нормализацией данных, что бы иметь представление о том что это такое и с чем это едят. Вопрос достаточно пространный, описывает достаточно абстрактную ситуацию.
У DBA есть свой подход к формированию источников данных он тяготеет к уплотнению и повышению производительности доступа, однако это одна сторона медали.
Я бы сказал, что моделирование источников данных это всегда поиск компромиса между производительностью, гибкостью и предсказуемостью. Если первые два понятия думаю особых вопросов не должны вызывать то последнее пожалуй стоит пояснить. Схема данных, описывающая структуру таблиц, фактически сообщает нам все необходимые сведения для обработки данных, такие данные можно считать предсказуемыми их обработка не требует никакой дополнительной логики направленной для выявления структуры. Схема базы строго соотвествует декомпозиции классаов (в общем смысле) для абстрации нашего приложения. Если сущностей не много и их описание заранее известно то это и будет иделаьным решением. Однако есть множество вариантов когда все свойства сущностей заранее не известны, не определены четко правила их объединения, да и сами сущности могут добавляться без заранее заданных правил категорирования. В этом случае применяются различные приемы направленные на отказ от честкой структуры (перенос структуры из схемы в данные). Применение антипаттрена EAV, использование полей JSON позволяет хранить произвольные данные, но требует дополнительных затрат по анализу структуры. В этом варианте JSON явяется перпективным направлением и нативно поддерживается в PostgreSQL. Вы можете сохнанить список телефонов как поле JSON, с ним будет проще рабоать штатными методами чем с вашим вариантом через ;. Так же JSON можно считать частично самодокументируемым данными содержащими и структуру и данные. Если мы считаем, что структура (схема данных) может быть предствлена подобно самим данным, а не как схема в привычном для нас понимании то мы подходим к варианту построения супер схем. Например фиксированный набор системных таблиц самого PostgreSQL позволяет описать любую произвольную схему данных для любой базы. Лично мне этот вариант нравиться больше. Я использую это решение для описание сложных данных в инженерных системах нормативно справочной информации, вполне успешно, так как этот подход позволяет разграничит данные о структуре и сами данные и как следствие оптимизировать призводительность и повысть предсказуемость отделив так сказать мух от котлет и при этом иметь статическую схему. Однако плата за это - необходимость использования REST API и сложности при разработке адаптеров данных под конкретную модель использования. Конструктор концепций
Получается, по сути, в посиках компромиса мы стараемся найти вариант недостатки котрого не помешают достичь желаемого результата в установленные сроки, так как дсотоинства редко кого отпугивают.