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

Question

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

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

Answer 1

См:

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

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

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

Answer 2

Не совсем отвечая на этот вопрос, но читатели могут заметить, что вокруг идеи MultValued Databases :

существует целая нишевая индустрия.

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

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

Answer 3

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

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

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

Mechanical Электрический

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

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

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

Jon

Answer 4

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

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

Answer 5

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

Сода -> Типы

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

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

Answer 8

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