Здравствуйте, Igor Trofimov, Вы писали:
A>>Как организовать список в базе данных A>>ну например хранить имнеа нескольких человек или массив данных в одном поле
iT>Лучше такого не делать. В любой БД. iT>Зачем тебе это нужно?
Ну например сохранить идентификационные номера нескольких пользователей ознакомившихся с некоторым документом
Здравствуйте, Aram119, Вы писали:
A>Ну например сохранить идентификационные номера нескольких пользователей ознакомившихся с некоторым документом
Заводишь табличку с полями:
ID пользователя, ID документа, дата ознакомления.
И все в эту табличку сохраняешь.
Вообщем надо тебе, для начала, почитать что-нибудь по реляционной теории, например Введение в системы баз данных Дэйта.
Здравствуйте, Aram119, Вы писали:
A>Как организовать список в базе данных A>ну например хранить имнеа нескольких человек или массив данных в одном поле
Это нарушает принципы хранения реляционных данных. Первая нормальная форма требует, чтобы в одном поле хранился ровно один элемент данных.
P/S/ иногда бывает необходимо все же нарушать это правило — в тех случаях, когда с точки зрения БД структурировать данные бессмысленно либо слишком неудобно. В качестве примера можно привести древовидные структуры малоразмерных элементов. Если вам нужно хранить что-нибудь типа формулы вычисления налога, то строить синтаксическое дерево и хранить его в нескольких таблицах неудобно и накладно. Вместо этого хранят прямо текст формулы. В последнее время мы часто используем XML в текстовом поле для хранения нереляционной части данных в MS SQL.
Но у вас совершенно точно не тот случай! Хранение списка в поле не позволит одним запросом получить обратную связь — например, вопрос "с какими документами ознакомлен данный человек" потребует полного сканирования и подъема в память списка документов.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В последнее время мы часто используем XML в текстовом поле для хранения нереляционной части данных в MS SQL.
а полнотекстовое индексирование пробовали по — что дает, что отнимает в сравнении со структурной разбивкой ...
Здравствуйте, KGP, Вы писали: S>>В последнее время мы часто используем XML в текстовом поле для хранения нереляционной части данных в MS SQL. KGP>а полнотекстовое индексирование пробовали по — что дает, что отнимает в сравнении со структурной разбивкой ...
Нет, не пробовали. А оно нам ни к чему — это не тексты. Это просто нереляционные данные Они не участвуют в запросах вообще никак. Монолит. Можно считать это сериализованным представлением некоторого объекта.
А для всяких списков — зуб даю, что нормализованное представление порвет любой fulltext как тузик грелку.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А для всяких списков — зуб даю, что нормализованное представление порвет любой fulltext как тузик грелку.
не дразни зверя! он и так всё время в бой рвется...
фу! фу Тузик! положи на место fulltext! я кому сказал! фу! зараза! ну всё! мое терпени лопнуло! где моя любимая палка?! а! испугался!!! вот и сиди. и не трогай больше бедный fulltext!
... << RSDN@Home 1.1 beta 2 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Hello, "Aram119" > > A>>Как организовать список в базе данных > A>>ну например хранить имнеа нескольких человек или массив данных в одном поле > > iT>Лучше такого не делать. В любой БД. > iT>Зачем тебе это нужно? > > Ну например сохранить идентификационные номера нескольких пользователей ознакомившихся с некоторым документом
В случае, если по этой информации не планируется устраивать поиск — можно использовать varchar поле и XML
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Hello, "Aram119" >> >> A>>Как организовать список в базе данных >> A>>ну например хранить имнеа нескольких человек или массив данных в одном поле >> >> iT>Лучше такого не делать. В любой БД. >> iT>Зачем тебе это нужно? >> >> Ну например сохранить идентификационные номера нескольких пользователей ознакомившихся с некоторым документом
TK>В случае, если по этой информации не планируется устраивать поиск — можно использовать varchar поле и XML
Вот вот именно эти три копеечки и я хотел добавить. Народ клепая базы данных совершенно незадумывается о том что ХРАНИМ, а что ОБРАБАТЫВАЕМ. так и получается вместо поля адрес — ул. дом. корп. секц. кв. Что делает базу неприг. для изм.
Мы уже победили, просто это еще не так заметно...
Они не участвуют в запросах вообще никак. Монолит. Можно считать это сериализованным представлением некоторого объекта.
Вот вот именно эти три копеечки и я хотел добавить. Народ клепая базы данных совершенно незадумывается о том что ХРАНИМ, а что ОБРАБАТЫВАЕМ. так и получается вместо поля адрес — ул. дом. корп. секц. кв. Что делает базу неприг. для изм. 
