Структура базы данных относительно динамических записей - Одна строка или несколько строк?

StackOverflow https://stackoverflow.com/questions/262361

  •  06-07-2019
  •  | 
  •  

Вопрос

Я пытался разработать схему базы данных для побочного проекта, но мне не удалось создать ничего, что меня устраивало бы.Я использую ASP.Net с LINQ для доступа к моим данным:

Я собираюсь разрешить пользователям указывать до 10 "элементов", каждый из которых имеет 2 числовых свойства и 1 ссылочное свойство - имя элемента.

Если бы я поместил эту запись в 1 строку, она легко равнялась бы более чем 30 столбцам (минимум), напримерitem_1_name (ссылка) item_1_weight item_1_volume item_2_name...и т.д...

И я не могу просто превратить эти столбцы в ссылочные таблицы, поскольку каждое свойство может существенно варьироваться от 1 до 400+.

Я также понял, что если пользователь решит поместить в свою запись только 1 элемент, метод, с помощью которого я создаю объект для этих данных, будет статическим, поскольку в LINQ мне пришлось бы проверить, являются ли свойства и еще много чего равными NULL, и работать соответствующим образом.Кроме того, если бы я когда-нибудь захотел увеличить количество элементов, разрешенных для записи, работа с этим была бы головной болью.

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

Есть ли что-то, что я упускаю из виду в своем дизайне / есть ли намного лучший и эффективный способ сделать это?

Редактировать:Когда я говорю, что он будет расти астрономически, я имею в виду именно это:Пользователь может создать запись, и каждая запись, скорее всего, будет содержать группу элементов.Допустим, они делают 1 запись на сайт в день, у них могло бы быть 3 группы товаров с максимальным количеством товаров (10), что равнялось бы 30 товарам для этой единственной записи.Делайте запись каждый день в течение недели с такой скоростью, и у вас могло бы быть 210 строк для этого одного пользователя.

Это было полезно?

Решение

Я бы порекомендовал последний вариант, который вы упомянули, создайте одну зависимую таблицу с пятью столбцами: 

CREATE TABLE Items (
  user_id               INTEGER NOT NULL,
  item_id               INTEGER NOT NULL DEFAULT 1,
  numeric_property1     INTEGER,
  numeric_property2     INTEGER,
  referential_property  INTEGER,
  PRIMARY KEY (user_id, item_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
                        ON DELETE CASCADE,
  FOREIGN KEY (item_id) REFERENCES num_items(item_id),
  FOREIGN KEY (referential_property) REFERENCES some_other_table(some_column)
);

Я показываю таблицу num_items выше, которая содержит цифры от 1 до 10, если вы хотите ограничить пользователей максимум 10 элементами: 

CREATE TABLE num_items (item_id INTEGER NOT NULL );
INSERT INTO num_items (item_id) 
  VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);

Преимущества этого дизайна в том, что COUNT () легко определить, сколько элементов имеет данный пользователь, легко вычислить такие вещи, как MIN () и MAX () для данного свойства, вы можете использовать внешний ключ для ссылочного свойства и т. Д.

Некоторые базы данных имеют функцию для объявления второй части составного первичного ключа (в данном случае item_id ) как автоинкремент, так что если вы укажете значение для entity_id но пропустите item_id , он автоматически получит следующее неиспользуемое значение (но не удалит пробелы, если вы удалите одно). Вы не указываете, какую марку базы данных вы используете, поэтому я предоставлю вам возможность выяснить эту функцию.

edit: Как говорит Тони Эндрюс в своем ответе, количество строк не является проблемой. Вы не указываете, какую марку базы данных вы собираетесь использовать, но если вы не выберете особенно слабый продукт, такой как MS Access, вы можете положиться на базу данных, чтобы легко обрабатывать миллионы строк. Если вы правильно выбираете индексы и пишете запросы, использующие эти индексы, эффективность не должна быть проблемой.

Другие советы

используйте таблицу с одним элементом:

Идентификатор пользователя, ItemIndex, isReference, числовое значение, ссылочное значение

таким образом, значение для item_3_name для пользователя 999 преобразуется в

999,3, true, null, значение

Вам придется самостоятельно вводить определенные ограничения, например.максимальное количество элементов на пользователя и т.д.

Правильный дизайн базы данных должен был бы хранить каждого пользователя / элемент в отдельной строке. С этим будет намного проще работать, и уберется произвольное ограничение в 10 элементов. Я бы не сказал, что он будет расти «астрономически глубоко», будет около 10 х (количество пользователей) строк.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top