PostgreSQL - целочисленный [] лучший метод

Question

В последнее время работая над веб-приложением, я решил использовать целое число [] в модели данных. Имея 2 таблицы, одну с данными статей, а другую с тегами (идентификатор тега и описание), решил идентифицировать теги, с которыми статья будет помечена в столбце article.tags integer [].

Как Милен А. Радев указал:

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

Не только это, но и необходимость работать с целым числом [] с использованием JDBC и iBatis, скажем так, «интересно».

На данный момент я могу сойти с рабочего внедрения на месте для того, что я должен был сделать. Вероятно, для простоты он будет переработан с использованием отдельной таблицы, хранящей отношения article.id и tag.id.

В конце концов, я озадачен тем, для чего лучше всего использовать целое число [] и в каком контексте?

Думаю, я сообразно понял, для чего это не лучше.

Answer 1

Я использовал массивы в PostgreSQL при работе с древовидными структурами, такими как потоки комментариев. Вы можете сохранить путь от корня до вашего узла в виде массива номеров ветвей. Затем вытащить все дерево в правильном порядке отображения просто:

SELECT stuff
FROM comments
WHERE thread = X
ORDER BY path -- This would be the array.

PostgreSQL сравнивает массивы единственным разумным способом. Использование массива для пути от корня также дает вам простой способ вычислить глубину узла. Вы можете использовать строку (скажем, 3 базовых 96 цифры на номер ветви) и ASCII-бетическую сортировку для той же цели, но массив намного яснее.

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

Не совсем специфично для Java, но в некоторых случаях массивы являются естественным и полезным представлением (даже в SQL) имеющихся данных.

Answer 2

Я могу вспомнить три приложения:

Первое - для денормализации.Компромиссы включают в себя: Вы не можете легко обновить или обработать элементы по отдельности.Но легко и быстро получить их все сразу.Это также экономит много места.

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

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

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

Answer 3

ИМХО, поскольку любой массив является нарушением 1NF, лучшим контекстом является: ... (барабанная дробь) ..... нет.

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

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

РЕДАКТИРОВАТЬ: Выше я сказал: «Я уверен, что они существуют ...» Посмотрите на @mu слишком короткий ответдля примера.

Answer 4

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

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

Answer 5

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

Еще одно использование будет график. Каков результат за тестовый прогон. Тестовые прогоны имеют 6 результатов. строка, целое число [] - массив из 6 результатов.