Это плохой дизайн для использования массивов в базе данных?
поэтому я создаю базу данных для личного проекта, чтобы получить больше, чем мои ноги мокрые с PostgreSQL и некоторыми языками и приложениями, которые могут использовать базу данных PostgreSQL.
Я пришел к пониманию, что использование массива не обязательно даже совместимо (массивы не являются атомарными, верно?) с 1НФ. Поэтому мой вопрос: есть ли недостаток эффективности или безопасности данных таким образом? Должен ли я рано научиться не использовать массивы?
4 ответов
короткий ответ на титул: нет
немного дольше ответ:
вы должны научиться использовать массивы при необходимости. Массивы сами по себе неплохой дизайн, они такие же атомарные, как и символьное переменное поле (массив символов, нет?) и они существуют, чтобы сделать нашу жизнь проще, а наши базы данных быстрее и легче. Существуют проблемы с переносимостью (большинство систем баз данных не поддерживают массивы или делают это по-другому, чем И Postgres)
пример:
у вас есть блог с постов и тегов, и каждый пост может иметь 0 или более тегов. Первое, что приходит на ум, это сделать другую таблицу с двумя столбцами postid и tagid и присвоить теги в этой таблице.
Если нам нужно искать сообщения с tagid, то необходима дополнительная таблица (с соответствующими индексами, конечно).
но если мы хотим, чтобы информация о теге отображалась только как дополнительная информация о сообщении, затем мы можем легко добавить столбец целочисленного массива в таблицу сообщений и извлечь оттуда информацию. Это все еще может быть сделано с дополнительной таблицей, но использование массива уменьшает размер базы данных (нет необходимых дополнительных таблиц или дополнительных строк) и упрощает запрос, позволяя нам выполнять наши запросы выбора с присоединением к одной таблице меньше и кажется более легким для понимания человеческим глазом (последняя часть находится в глазу зрителя, но я думаю, что говорю за большинство здесь). Если наши теги поджали, тогда не нужно даже одного соединения.
пример может быть бедным, но это первое, что пришло на ум.
вывод:
массивы не нужны. Они могут быть вредными, если вы используете их неправильно. Вы можете жить без них и иметь отличную, быструю и оптимизированную базу данных. Когда вы рассматриваете переносимость (например, перезапись системы для работы с другими базами данных), вы не должны использовать массивы.
Если вы уверены, что будете придерживаться Postgres, то вы можете безопасно использовать массивы, где вы найдете подходящее. Они существуют по какой-то причине и не являются ни плохим дизайном, ни несовместимыми. Когда вы используете их в нужных местах, они могут немного помочь с простотой структур базы данных и вашего кода, а также с оптимизацией пространства и скорости. Это все.
является ли массив является атомарным зависит от того, что вас интересует. Если вы вообще хотите весь массив, то он атомарный. Если вас больше интересуют отдельные элементы, то он используется как структура. Текстовое поле-это в основном список символов. Однако обычно нас интересует вся цепочка.
теперь-с практической точки зрения, многие фреймворки и ORMs не распаковывают автоматически типы массивов PostgreSQL. Также, если вы хотите перенести базу данных например, MySQL, тогда вы будете
аналогично, ограничения внешнего ключа не могут быть добавлены в массив (если только он не находится в 9.3 - no, похоже, нет).
Я считаю, что массивы являются полезным и соответствующим оформлением в тех случаях, когда вы работаете с такими данными и хочет использовать всю мощь SQL для запросов и анализа. Я начал использовать массивы PostgreSQL регулярно для научных целей, а также в PostGIS для крайних случаев в качестве примеров.
в дополнение к хорошо объясненным проблемам, упомянутым выше, я нахожу самую большую проблему в получении сторонних клиентских приложений, чтобы иметь возможность обрабатывать поля массива способами Я ожидал. Например, в Tableau и QGIS массивы обрабатываются как строки, поэтому операции с массивами недоступны.
массивы являются типом данных первого класса в стандарте SQL и обычно позволяют более простую схему и более эффективные запросы. Массивы, в общем, отличный тип данных. Если ваша реализация является автономной и не требует использования сторонних инструментов без API или другого промежуточного программного обеспечения, которое может иметь дело с несовместимостью, используйте массив поле.
Если, однако, вы взаимодействуете со сторонним программным обеспечением, которое напрямую запрашивает БД, и массивы используются для создания запросов, то я бы избегал их в пользу более простых таблиц поиска и других традиционных реляционных подходов.
короткий ответ: Да, это плохой дизайн. использование массивов гарантирует, что ваш дизайн не 1NF, потому что для 1NF не должно быть повторяющихся значений. Правильный дизайн однозначен: сделайте другую таблицу для значений массива и присоединитесь, когда вам это нужно.
массивы являются особенностью Postgres. В этом нет ничего стандартного. Возможно, это все еще подходящий инструмент для работы в определенных ограниченных обстоятельствах, но я все равно буду стараться избегать их. Они-последнее средство, и они свяжут вас с Постгресом. Вы можете или не заботиться об этом, но есть (IMO) гораздо лучшие причины для брака с Postgres, чем массивы.
самая большая проблема с массивами заключается в том, что они клюкой. Вы уже знаете их и хотите использовать, потому что они вам знакомы. Но они работают не совсем так, как вы ожидаете, и они позволят вам только отложить истинное понимание SQL и реляционных баз данных. Ты намного лучше. ожидая, пока вы будете вынуждены использовать их, чем изучать их и искать возможности полагаться на них.