Вопрос о термине базы данных
это назвало разделенный запятыми список пар значения атрибута и является совершенно допустимой вещью сделать...
... при редких и исключительных обстоятельствах!
Я с Paul; "Глупый" первое слово, которое прибывает по моему мнению.
-
1" dumb" было первое слово, о котором я думал, но " stupid" работы для меня. второй вещью, о которой я думал, был " немой, но уныло common". – cas 13 August 2009 в 04:00
-
2Например, Вы видите его на The Daily WTF об один раз в неделю. – Paul Tomblin 13 August 2009 в 04:13
-
3хорошо, парни, у нас есть таблица журнала со столбцом, содержащим много различных значений. Это имеет имя? Да или номер я попробую переполнение стека иначе. – madphp 13 August 2009 в 05:27
-
4Uuh, это не полезно вообще. CSV является совершенно допустимым способом передать небольшие количества строковых значений для некогда от импорта/экспорта. Excel может считать их из поля (и смог к с тех пор навсегда), как может Получить доступ, SSMS и they' ре, человекочитаемое в блокноте для начальной загрузки. – Mark Henderson♦ 14 August 2009 в 04:43
-
5Ack, извините, я просто видел это it' s не CSV вообще. You' право ре, это глупо. – Mark Henderson♦ 14 August 2009 в 04:46
BTW, причина, почему это является "немым" или "глупым" или "действительно плохая идея", то, что это лучше сделано как отдельная таблица с полевым указанием внешнего ключа назад на идентификационное поле в первой таблице, "ключевое" поле и поле "значения". это позволяет парам ключ/значение индивидуально индексироваться, искаться, и управляться (добавьте, удалите, обновление).
и даже затем, это только полезно при некоторых обстоятельствах - где существует переменное количество неизвестных/произвольных ключей, которые данная запись, возможно, связала с собой. если имя и номер ключей известно заранее, существуют лучшие способы обработать его.
Википедия имеет несколько хороших вводных статей о базах данных и нормализации базы данных, которые стоит считать. запустите с Нормализации Базы данных и Моделей базы данных
-
1+1 It' s достаточно легкий сказать it' s немой, но намного более ценный для объяснения, почему. Без хорошего " why" немые вещи просто повторяются. – John Gardeniers 14 August 2009 в 06:06
Согласно нескольким книгам по моей полке, термин, который Вы ищете:
В то время как существуют исключения к каждому правилу, многослойные поля редко необходимы.
Многослойные поля могут нанести ущерб с целостностью данных и должны избежаться. Проблемы чаще всего подходят, когда Вы пытаетесь отредактировать, удалить или отсортировать дату в многослойном поле.
Когда Вы "нормализуете" свою базу данных и удостоверяетесь, что каждое поле хранит только единственное значение, Вы делаете себя (и другие) огромная польза в будущем, помогая гарантировать, чтобы у Вас были целостность данных и достоверная информация.
Я называю это нарушением первой нормальной формы.
Я соглашаюсь, это глупо
ЕСЛИ
это - модель данных Вашего приложения.
Это на самом деле довольно выгодно при простом сохранении чего-то, что было проанализировано в другом месте, такие как пользовательские опции в клиентском приложении. Делает клиент к работе парсинга. Это - тривиальный механизм хранения, который может легко быть разделен и сохранен в клиентском наборе.
Свободно, это - "повторяющееся значение" и нарушает (по крайней мере), Первую Нормальную форму (вид): http://en.wikipedia.org/wiki/Database_normalization
Это - то, как я предпочел бы делать это, если Вы будете делать что-нибудь с этими данными помимо простого сохранения его.
id | opt | content
1 | 1 | this
1 | 2 | that
1 | 3 | other
2 | 1 | this
2 | 2 | that
2 | 3 | other
3 | 1 | this
3 | 2 | that
3 | 3 | other