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