Многозначные поля хорошая идея?
Если я помню правильно, можно сделать это путем создания .gitignore файл в sessions папка с [^.]* как ее содержание.
5 ответов
Идея многозначных полей заключалась в поддержке простого создания объектов отчета / интерфейса, кроме того, можно создать форму, которая отображает, скажем, категории для проблемы. Вместо интенсивной работы, не дай бог присоединится, якобы проще было сохранить:
Mechanical, Electrical
как значение в поле, а не
Mechanical Электрооборудование
Лично мне это не нравится, и я предполагаю, что этот тип поля был создан для нетехнического персонала, такого как бухгалтеры :) (шучу). Нет, серьезно, не используйте это, если только вы не создаете глупый инструмент, которым редко кто-нибудь будет пользоваться и редко кому когда-либо придется подключаться.
Надлежащий способ справиться с этим - соединения, без дубликатов и без множественных значений внутри столбцы (в любом случае это все 3nf).
Другая причина, по которой это было создано, заключалась в поддержке множественных значений внутри списка sharepoint.
Джон
См .:
Многозначные типы данных считаются вредными: насколько опасным может быть тип данных?
Я долго разговаривал с Сураджем Poozhiyil, Программа доступа Менеджер ... и Сурадж, и я согласны искренне, что разработчики не необходимо использовать многозначные поля. Люди, разбирающиеся в базах данных уже есть хороший способ реализация многих для многих отношения и пользы не будет из многозначных полей.
Итак, мой ясный и верный совет разработчикам не следует использовать многозначные поля. Им нечего нам предложить кроме потенциальной боли.
Большой сегмент рынка Access не относится к разработчикам, но носит технический характер, пользователей. Они могут не понимать значения нормализации, но они могут заставить что-то работать. Им просто нужно что-то простое, и это лучше, чем поле с произвольным текстом, в которое люди вводят, где, как вы надеетесь, все они вводят одно и то же.
По мере того, как они узнают больше, они могут начать использовать другие таблицы и внешние ключи. Но иногда достаточно многозначного поля.
ПРОСТО СКАЗАТЬ НЕТ!
если вы изучаете SQL, изучите правильный путь и нормализуйте свои таблицы. если вы знаете дизайн базы данных, сделайте это правильно. Не все функции должны использоваться.
Не совсем отвечаю на вопрос, но читатели, возможно, захотят отметить, что существует целая ниша индустрии вокруг идеи Многозначных баз данных:
Эти базы данных отличаются от реляционной базы данных тем, что они имеют функции, которые поддерживают и поощряют использование атрибутов, имеющих список значений, а не все атрибуты имеют одно значение
Так как в этом случае механизм базы данных имеет расширения языка запросов для учета многомерной природы таблиц (чего, я полагаю, Access, вероятно, не имеет), то это не совсем сравнимо с многозначными полями в Access. Но в любом случае это интересная параллель (для тех, кто раньше даже не слышал о многозначных базах данных).