|
|
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
Проектируется база данных SQL Server Подскажите, пожалуйста. Есть объект с характеристиками разного типа. Часть характеристик статических - заносятся при "рождении" объекта, часть динамически меняется. Стоит ли разделить эти данные на две таблицы - в одной хранить то что не меняется (не проходит операция update), а в другой все остальные. Логически это разные данные, а принадлежат одному объекту. Какие плюсы или минусы каждого варианта - все в одной таблице или в разных. Огромная просьба помогите обосновать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2007, 10:34 |
|
||
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
HeartПроектируется база данных SQL Server Подскажите, пожалуйста. Есть объект с характеристиками разного типа. Часть характеристик статических - заносятся при "рождении" объекта, часть динамически меняется. Стоит ли разделить эти данные на две таблицы - в одной хранить то что не меняется (не проходит операция update), а в другой все остальные. Логически это разные данные, а принадлежат одному объекту. Какие плюсы или минусы каждого варианта - все в одной таблице или в разных. Огромная просьба помогите обосновать. Ну, блин, все же было сказано в предыдущей Вашей теме - читайте про нормализацию таблиц, нормальные формы, выделение функциональных зависимостей, ER-диаграммы и т.д. Какой смысл нам здесь пересказывать основы проектирования БД, изложенные в "учебниках" типа Дейт "Основы проектирования баз данных". Возьмите и почитайте ... Если отбросить эмоции, то по Вашей постановке я вижу такое решение: 1. Таблица объектов в виде (id объекта, наименование объекта) 2. таблица характеристик (id характеристики, название характеристики) 3. Характеирстики объекта(id объекта, id характеристики, Value) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2007, 11:19 |
|
||
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
Станислав С...кий Если отбросить эмоции, то по Вашей постановке я вижу такое решение: 1. Таблица объектов в виде (id объекта, наименование объекта) 2. таблица характеристик (id характеристики, название характеристики) 3. Характеирстики объекта(id объекта, id характеристики, Value) Совет "почитать Дейта" у меня отрицательных эмоций не вызывает. А вот предлагаемое вами решение - вызывает. Подсовывать человеку EAV, как рецепт на все случаи жизни, это, по меньшей мере, не гуманно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2007, 14:59 |
|
||
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey Станислав С...кий Если отбросить эмоции, то по Вашей постановке я вижу такое решение: 1. Таблица объектов в виде (id объекта, наименование объекта) 2. таблица характеристик (id характеристики, название характеристики) 3. Характеирстики объекта(id объекта, id характеристики, Value) Совет "почитать Дейта" у меня отрицательных эмоций не вызывает. А вот предлагаемое вами решение - вызывает. Подсовывать человеку EAV, как рецепт на все случаи жизни, это, по меньшей мере, не гуманно. Согласен с Вами... Однако, была постановка задачаи "в общем":Есть некий объект, есть некие атрибуты объекта. И ни слова о том, принадлежат ли объекты одному или разным классам, имеют ли одинкаковый набор атрибутов или нет, являются ли одни их атрибуты производными от других и т.д. В общем, никакой конкретики... Поэтому и решение "в общем" (чтобы подходило под все случаи жизни). И я нигде не говорил, что это оптимальное решение... Конечно, если будет конкретика, то можно будет человеку и порекомендовать что-то конкретное... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2007, 15:17 |
|
||
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
Станислав С...кий[Конечно, если будет конкретика, то можно будет человеку и порекомендовать что-то конкретное... Это действительно так. Например, если отделить статичную и динамичную информацию можно делать выборочную архивную копию БД, а не всю целиком (для больших БД это актуально), можно также установливать разные уровни доступа к таблицам со статичной и динамичной информацией, зависит от того, надо ли создавать многостолбцовый (составной) индекс по статичным и динамичным полям (тогда они должны быть в одной таблице) и т. п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2007, 20:10 |
|
||
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
ок. может я не корректно задаю вопрос. Меня по большому счету интересует, какие проблемы могут возникнуть у широких таблиц со многим количеством полей по которым должен идти поиск. А насчет конкретики. Каждая характеристика это отдельное поле. Вроде бы нет необходимости делать структуру как предложено автор1. Таблица объектов в виде (id объекта, наименование объекта) 2. таблица характеристик (id характеристики, название характеристики) 3. Характеирстики объекта(id объекта, id характеристики, Value) Вродк лучше где поле является названием характеристики таблица объектов с характеристиками id объекта, value характеристики1, value характеристики2, value характеристики3 и т.д. Или я в чем то не права? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2007, 12:16 |
|
||
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
Heartок. может я не корректно задаю вопрос. Меня по большому счету интересует, какие проблемы могут возникнуть у широких таблиц со многим количеством полей по которым должен идти поиск. Некоторые проблемы могут возникнуть: а) У некоторых СУБД есть ограничение на количество полей (что-то порядка 256) в одной таблице. б) Если в таблице много строковых полей переменной длины, которые часто модифицируются, то могут появиться так называемые chained rows, которые неблагоприятно сказываются на производительности. Аналогичные проблемы могут возникнуть и если просто записи по ширине не влезают в один блок. в) программистам не очень удобно работать с широкими таблицами - приходится долго искать нужное название поля и т.п. Но от разделения на несколько таблиц проблем в общем случае - больше. Heart Вродк лучше где поле является названием характеристики таблица объектов с характеристиками id объекта, value характеристики1, value характеристики2, value характеристики3 и т.д. Или я в чем то не права? Вы совершенно правы. Просто многие люди любят так называемую EAV структуру, считая ее универсальным средством для хранения атрибутики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2007, 12:57 |
|
||
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
HeartМеня по большому счету интересует, какие проблемы могут возникнуть у широких таблиц со многим количеством полей по которым должен идти поиск. Проблемы могут возникнуть две. Первая проблема: по многим полям должен идти поиск, значит для поиска по полям лучше всего построить индексы, а каждый индекс будет значительно тормозить update и insert. Вторая проблема: если читаются или обновляются большие объёмы данных, то чем ближе они располагаются, тем меньше требуется операций чтения/записи жёсткого диска. А это самые медленные операции на компьютере. Соответственно, операции обновления/чтения нескольких столбцов с маленькой таблицей идут значительно быстрее, чем с большой. Таким образом, если Вы вынесете часто обновляемые или запрашиваемые данные в отдельную таблицу, Вы получите значительную прибавку в скорости базы. Иногда в десятки раз. К сожалению, это полностью противоречит идее EAV структуры -:-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2007, 21:30 |
|
||
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
NoGuest Соответственно, операции обновления/чтения нескольких столбцов с маленькой таблицей идут значительно быстрее, чем с большой. А если вылазят за предел страницы (чем любят пользоваться СУБД),то какова вероятность, что данные одной записи будут размещены рядом, на на расстоянии выстрела? NoGuestТаким образом, если Вы вынесете часто обновляемые или запрашиваемые данные в отдельную таблицу, Вы получите значительную прибавку в скорости базы. Иногда в десятки раз. К сожалению, это полностью противоречит идее EAV структуры -:-) если Вы разделите в принципе OLTP и OLAP.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2007, 02:07 |
|
||
|
Таблицы
|
|||
|---|---|---|---|
|
#18+
iscrafm NoGuest Соответственно, операции обновления/чтения нескольких столбцов с маленькой таблицей идут значительно быстрее, чем с большой. А если вылазят за предел страницы (чем любят пользоваться СУБД),то какова вероятность, что данные одной записи будут размещены рядом, на на расстоянии выстрела?Тогда чем длиннее столбец (больше данных), тем больше нужно будет обработать таких страниц. Компактность данных, с которыми идёт работа, - всегда преимущество. Даже если расстояние между данными 8-16 байт. У расстояния между данными 8 байт преимущество по скорости вдвое выше, чем у 16. iscrafm NoGuestТаким образом, если Вы вынесете часто обновляемые или запрашиваемые данные в отдельную таблицу, Вы получите значительную прибавку в скорости базы. Иногда в десятки раз. К сожалению, это полностью противоречит идее EAV структуры -:-) если Вы разделите в принципе OLTP и OLAP....У топикстартера сказано: "Часть характеристик статических - заносятся при "рождении" объекта, часть динамически меняется", так что разделит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2007, 11:35 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=34663336&tid=1544354]: |
0ms |
get settings: |
9ms |
get forum list: |
23ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
183ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
| others: | 215ms |
| total: | 519ms |
| 0 / 0 |
