Трехмерная таблица базы данных
мы все были там - рассмотрим следующий пример - во-первых, клиент говорит: "каждый пользователь должен иметь только одну фотографию профиля", поэтому мы добавляем поле для этого в таблицу пользователей-полгода спустя требования меняются, и пользователю действительно нужно иметь N фотографий профиля.
теперь это кажется возможным только при добавлении новой таблицы, такой как user_pictures для обработки новой мощности 1:n вместо 1:1. Часто это может быть очень сложно. Всякий раз, когда я сталкиваюсь с этим проблема, интересно, почему мы не используем все три измерения, в которых мы можем думать. Двумерная таблица ограничена таким образом, что она несколько неполная - что, если, ссылаясь на нашу проблему с изображением профиля снова, поле изображения в таблице пользователей имело глубина, и эта глубина сделала поле массивом, который отлично представлял обе мощности 1:1 и 1: n одновременно.
поля таблицы просто станут массивами и автоматически поддержат оба кардиналы-разве это не здорово? По крайней мере, я им воспользуюсь. Что-то подобное уже есть?
3 ответов
Oracle поддерживает массивы а также вложенные таблицы. Любой из них, кажется, соответствует вашим требованиям. В наши дни, хотя люди предпочитают моделировать все как таблицы и отношения, чтобы держать вещи простыми и последовательными, и поэтому современные RDBMSes обычно не поддерживают этот материал, и я не верю, что он когда-либо попадал в стандартный SQL.
стандартный подход "многие ко многим", многие пользователи ко многим фотографиям профиля, легко покрывается подходом с тремя таблицами:
Таблицы: Пользователи
Таблица: Картинки
Таблица: User_Pictures
однако, если вы перейдете к подходу NoSQL, вы можете сохранить пользовательский документ (обычно в формате JSON), который хранит массив изображений профиля для этого пользователя в одной таблице.
@gordy +1 для ссылки Oracle. Я не был уверен, что rdbs предполагал матрицы.
вы описываете метод денормализации (несколько столбцов для экземпляров одного поля), и это обычно приводит к слезам, если вы не полностью понимаете последствия нарушения основных реляционных принципов.
классическая трудность возникает, когда вы хотите запросить на поле ("найти пользователя, у которого есть это изображение"), и вы обнаружите, что оператор SQL С "и изображением в (pic1, pic2, pic3)" не может быть проиндексирован, и ваш оптимизатор начинает планировать свою месть.