Многозначные поля — хорошая идея?

Question

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

Есть ли хорошее применение этим полям, которое не заставит меня чувствовать себя грязным?

Answer 1

Идея многозначных полей заключалась в том, чтобы облегчить создание объектов отчета/интерфейса, кроме того, можно создать форму, которая отображает, например, категории для проблемы.Вместо того, чтобы заниматься какой-то интенсивной работой, не дай бог присоединяется, якобы было проще хранить:

Механический, Электрический

как значение в поле, а не

Механическая электрическая

Лично мне это не нравится, и я предполагаю, что этот тип поля был создан для нетехнического персонала, такого как бухгалтеры :) (шучу).Нет, серьезно, не используйте это, если вы не создаете глупый инструмент, который редко кто-то будет использовать и к которому редко кому-либо придется подключаться.

Правильный способ справиться с этим — соединения, отсутствие дубликатов и отсутствие нескольких значений внутри столбцов (в любом случае это все 3nf).

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

Джон

Answer 2

Видеть:

Многозначные типы данных считаются вредными:Насколько опасным может быть тип данных?

У меня был долгий разговор с Сурадж Пужхийлом, менеджером программы доступа ...И Сурадж, и я искренне согласны с тем, что разработчикам не нужно использовать многозначные поля.Люди, которые понимают базы данных, уже имеют хороший способ внедрить многие ко многим отношениям и не получат пользы от многозначных областей.

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

Answer 3

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

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

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

Answer 4

Большой сегмент рынка доступа составляют не разработчики, а технические пользователи.Они могут не понимать ценности нормализации, но они могут заставить что-то работать.Им просто нужно что-то простое, и это лучше, чем поле со свободным текстом, куда люди вводят текст, и вы надеетесь, что все они напишут одно и то же.

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

Answer 5

многозначные поля могут легко избавить вас от необходимости создавать новую таблицу и связь.

Газировка --> Виды

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

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

Answer 6

ПРОСТО СКАЗАТЬ НЕТ!
если вы изучаете SQL, учитесь правильно и нормализуйте свои таблицы.если вы знаете, как проектировать базы данных, делайте это правильно.Не все функции должны быть использованы.

Answer 7

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

Вопрос: «Многозначные поля — хорошая идея?»

Реальный вопрос, который следовало бы задать: «Многозначные поля в СУБД — хорошая идея?»

Как отмечали другие, существует целая модель MVDBMS, поддерживающая многозначные поля.Я эксперт в этой области и работаю с моделью более 30 лет.Конечно, это хорошая идея, по моему мнению и для других, кто использует платформу каждый день.И да, Caché не только имеет отличную многомерную модель, но и поддерживает модель MVDBMS.Так что в этом отношении ответ на вопрос – ДА.

Но для СУБД и, в частности, для MS ACCESS ответ почти наверняка НЕТ, поскольку ни модель СУБД, ни эта платформа по своей сути не поддерживают эту концепцию.

Принятый ответ правильный, ИМО, поскольку он не просто отвечает на заданный вопрос, он отвечает на вопрос, который должен был быть задан.Но если быть дотошным, то на заданный вопрос принятый ответ неверен.

Я считаю, что реальный ответ таков: «Хорошо, если платформа СУБД поддерживает это, ДА для MVDBMS и, возможно, других платформ NoSQL, НЕТ для СУБД».

Answer 8

Мне очень не нравятся многозначные поля.Возможно, они сделали это, чтобы упростить взаимодействие с другими многозначными системами, такими как старая система PICK/Unidata.Могу поспорить, что увеличивать размер базы данных Access с интенсивным использованием этой новой функции SQL Server — это весело.