|
|
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
Не первый раз сталкиваюсь с тем, что на крупных системах таблицы разворачивают горизонтально (растягивают в ширь, так сказать). Получаются таблицы с сотнями полей. При чем свегда говорится, что да это плохо, но теперь уже не переделать, поэтому вот так :) Какие минусы в этом (горизонтальном хранении) вижу я: - сразу падают возможости по масштабированию системы (то есть теперь вместо того, чтобы просто добавить строку в справочник, (что может сделать и пользователь) нам надо добавлять поле в таблицу можно сказать, с полным циклом разработки) - громоздские запросы (вместо того, чтобы написать маленький апдейт/селект, приходится писать апдейт с перечислением кучи однотипынх полей) - чаще приходится применять динамический sql (хотя да. это спорно) Какие плюсы: - плюс вижу только один и то по-моему сомнительный - мы можем написать один апдейт/инсерт с кучей полей, вместо сотен маленьких апдейтов/инсертов. Или это существенный плюс, который все перевешивает? Может я чего-то не понимаю и есть какие-то еще плюсы? Модератор: Тема перенесена из форума "Oracle". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2012, 09:05 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
ТуБиОрНотТуБиМожет я чего-то не понимаю и есть какие-то еще плюсы? В общем всё верно. Для укомплектования перечня плюсов и минусов (а также для добавления себе уверенности :) ) почитай ещё про EAV (крайний случай разворачивания в строки) и нормальные формы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2012, 09:23 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
Ок. В общем выходит, основной минус вертикального подхода - это скорость. Надо померить насколько это большой минус ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2012, 10:11 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
Что-то я не понял ваших минусов "горизонтального" подхода. ТуБиОрНотТуБи- сразу падают возможости по масштабированию системы (то есть теперь вместо того, чтобы просто добавить строку в справочник, (что может сделать и пользователь) нам надо добавлять поле в таблицу можно сказать, с полным циклом разработки) С какого бодуна сделано это утверждение? Что мешает пользователю добавить колонку в таблицу? Чем это сложнее добавления в какой-то справочник? Если количество байт в соответствующих командах сравнивать, то добавление колонки почти наверняка проще будет. ТуБиОрНотТуБи- громоздские запросы (вместо того, чтобы написать маленький апдейт/селект, приходится писать апдейт с перечислением кучи однотипынх полей)Ну тут просто все ровно наоборот - в "горизонтальном" подходе есть select *, который сразу представит данные в наглядном, а в "вертикальном" приходится писать многоэтажные монстры, дабы данные из базы пришли в удобоваримом виде. ТуБиОрНотТуБи- чаще приходится применять динамический sql (хотя да. это спорно) И опять же ворпрос - с какого бодуна? Видел множество систем вполне живущих себе без всякой "динамики". Более того, по секрету скажу, что динамический sql в том же Oracle появился не так уж давно, большие системы писали до этого и вполне успешно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2012, 11:09 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
Если гор. таблица не должна редактироваться в гриде, то ее можно создавать динамически. Имеем три датасета: горизонталь-вертикаль-факты. Создаем и заполняем вычисляемые поля фактов. Новые колонки это всего лишь новые строки в таблицах "вертикаль" и "факты". Никакого редизайна. Нечто подобное есть в Навижене. МатриксБокс. Эту мою фотку когда показывал (Делфи). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2012, 11:18 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
Bogdanov AndreyС какого бодуна сделано это утверждение? Что мешает пользователю добавить колонку в таблицу? Чем это сложнее добавления в какой-то справочник? Если количество байт в соответствующих командах сравнивать, то добавление колонки почти наверняка проще будет. А что даст пользователю добавление новой колонки? Кто будет ее обрабатывать? Ее обработку надо будет дописывать в серверной части (либо приходим к тому, что придется как раз использовать динамический sql, чтобы оперировать именами обрабатываемых полей). Плюс это новое поле придется протягивать в кучу различных запрсов... В случае же когда мы просто добавили запись (новое свойство сущности), то да скорее всего, нам тоже придется дописывать логику обработки, но не всегда. Bogdanov AndreyНу тут просто все ровно наоборот - в "горизонтальном" подходе есть select *, который сразу представит данные в наглядном, а в "вертикальном" приходится писать многоэтажные монстры, дабы данные из базы пришли в удобоваримом виде. Для наглядности можно использовать например материализованные или простые вьюшки. Но в целом согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2012, 12:44 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
ТуБиОрНотТуБиВ случае же когда мы просто добавили запись (новое свойство сущности), то да скорее всего, нам тоже придется дописывать логику обработки, но не всегда.Назовите мне случай, когда в "вертикальном" варианте обработку дописывать не придется, а в "горизонтальном" придется? Может быть вы не знаете о существовании словаря данных (он есть в любой СУБД) и пытаетесь заменить его своим справочником? ТуБиОрНотТуБиДля наглядности можно использовать например материализованные или простые вьюшки. Ой маладца... Сначала делаем свой велосипед, а потом, поняв, что ездить на нем неудобно, начинаем таки возможности СУБД использовать. И какой в этом прок - вместо простого alter table делаем кучу insert в свои словари и create view? А обработку данных из этих вьюшек Пушкин наверное напишет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2012, 15:10 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
По-моему у ненормализованной схемы данных есть только один плюс - минимум умственных усилий для её создания и сопровождения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2012, 20:59 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
Ares_ekbПо-моему у ненормализованной схемы данных есть только один плюс - минимум умственных усилий для её создания и сопровождения. Насчет легкости сопровождения как раз и не совсем очевидно. Возможен, редкостный гемор в общем случае. Ведь это может означат, что схеме нельзя навязать некоторых ОЦ декларативно. Могут быть возникнуть аномалии ввода, удаления. Необходимось контроль избыточности. Все это может при сопровождении вызвать напряги в каких-то случаях. Ну если базой никто не пользуется - типа учебная, то конечно сопровождение в легкую. А иначе риски все же есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2012, 21:50 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
ТуБиОрНотТуБиМожет я чего-то не понимаю и есть какие-то еще плюсы?По моему, неправильно расставлены акценты. В обоих случаях нужно просто добавить строку в справочник, в обоих случаях требуется проектирование и реализация модели данных, которое должно делаться проектировщиками по заданию бизнес-аналитиков. Но в случае EAV программисты полагают, что могут реализовать движок СУБД самостоятельно, а проектировать модели данных смогут и пользователи (и это выгодно, ведь секретаршам и ученикам сейлов платят меньше, чем архитекторам БД и оракловым ДБА)! Да, кстати, обычно это люди, которые по специальности к базам данных отношения не имеют, поэтому и всё знают. Их конечно удивляет, почему в РСУБД есть какие то языки DDL и DML, ведь нужно выпускать РСУБД с тремя встроенными таблицами - Объекты, Значения, и Объект-Значение, без возможности расширения. Ещё есть люди, которые думают, что не сумеют написать движок СУБД лучьше, чем фирмы, которые это делают десятки лет, это обычно те, кто как раз много лет работает с базами данных. "Неужели мы лучьше сможет сделать добавление строчки в справочник, чем это делает РСУБД, там же этот справочник продумывался десятки лет не самыми глупыми людьми" - думают они. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2012, 22:31 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
ТуБиОрНотТуБиОк. В общем выходит, основной минус вертикального подхода - это скорость. Надо померить насколько это большой минус ) Зависит от... На справочниках с объмом ~ 100К строк терпимо. На операциях ~ 1000К строк уже не очень. Там традиционный подход (с модификациями). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2012, 11:18 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
vadiminfo, я не говорил про легкость, а только про умственные усилия ) Т.е. сомнительный такой плюс ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2012, 17:35 |
|
||
|
Горизонтальный разворот таблиц vs вертикальный
|
|||
|---|---|---|---|
|
#18+
Ares_ekbvadiminfo, я не говорил про легкость, а только про умственные усилия ) Т.е. сомнительный такой плюс ) Ну я под легкостью имел в виду не работу пальцев на клаве. Хорошо. Скажем иначе - издержки на сопровождение в общем случае могут возрасти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2012, 23:17 |
|
||
|
|

start [/forum/topic.php?fid=32&tid=1541556]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
152ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 251ms |
| total: | 467ms |

| 0 / 0 |
