Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Оптимальная схема для множества документов / 21 сообщений из 21, страница 1 из 1
20.11.2010, 23:33
    #36967817
sunhare
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
Здравствуйте. Проблема в следующем. Бизнес-процесс разрабатываемого приложения подразумевает хранение документов нескольких типов. При этом у всех документов есть ряд общих полей - номер, дата, тип (ссылка на справочное значение), автор и ряд уникальных полей для каждого типа документа. Всего типов пока около 20-и, но в будущем возможно будет и больше.
Пока идея по этому куску схемы данных следующая. Сделать отдельную таблицу для "шапки" (общие поля) документа и для каждого конкретного "тела" (уникальные поля) документа собственную таблицу, которая бы ссылалась на "шапку".
Но эта схема кажется не очень красивой, тем более при возможном увеличении типов документа. Есть сомнения по поводу производительности при выборке всех документов по какому-либо параметру.
Какие есть предложения и замечания?
Заранее спасибо.
...
Рейтинг: 0 / 0
21.11.2010, 10:23
    #36967961
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
sunhare,
сделайте одну таблицу, и никаких проблем у Вас не возникнет
...
Рейтинг: 0 / 0
21.11.2010, 11:20
    #36968012
ПЕНСИОНЕРКА
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
sunhare,

может по принципу 1с(характеристики)

таб1 -основная
-ид1,дата,.............

таб2 -характеристика
-ид2,ид1,наименование хар-ки,значение(кроме OLE)

проблем со стыковкой не вижу, если конечно не супербольшая таблица
например в
1дверь2окно31дверь

11металлическая21с глазком1131утеплительввв42...531металлическая631с глазком12741...

-выборка с глазком -ид1=1,31
-select * from tab1 inner join rab2 on id1=id2 where id1 in(1,31)
-перекрестный запрос чтобы не думать есть в этом документе утеплитель или нет
наименованиес глазкомутеплительдверь11вввдверь12---
...
Рейтинг: 0 / 0
21.11.2010, 13:20
    #36968131
lLocust
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
sunhare,

Идея у Вас нормальная.
Если нужна скорость работы, то использовать вариант ПЕНСИОНЕРКИ не советовал бы.
Что бы постоит таблицу с n-характеристиками нужно сделать n-Left join`ов, что будет тормозить процесс.

Делать одну таблицу, если у Вас документы по типам очень разные - то же не вариант:
To Бредятина: представьте как вы в одной таблице храните накладную и акт ))))
а вот испоьлзование шапки (хотя здесь больше подходит понятие стержня, на который Вы как бы "нанизываете" ваши документы по ИД) вполне уместно.

По-поводу увеличения типов документов то же не стоит беспокоиться... Если они у вас будут увеличиваться, то создавать талицы вам придется так и так.
...
Рейтинг: 0 / 0
21.11.2010, 13:36
    #36968144
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
lLocustДелать одну таблицу, если у Вас документы по типам очень разные - то же не вариант:
To Бредятина: представьте как вы в одной таблице храните накладную и акт ))))
а вот испоьлзование шапки (хотя здесь больше подходит понятие стержня, на который Вы как бы "нанизываете" ваши документы по ИД) вполне уместно.

Мы вольно трактуем задачу, так как она не поставлена:)
Что значит "очень разные"?
Автор нигде не указал, что есть однородные "записи" в "документах".
Конечно, все документы нужно хранить в одной "таблице". Не будет никаких проблем:)
...
Рейтинг: 0 / 0
21.11.2010, 14:06
    #36968173
sunhare
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
Спасибо за ответы.
Уточню. Таблицы по типам действительно очень разные - в каждой будет более десятка уникальных для данного типа полей.
Есть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно.
...
Рейтинг: 0 / 0
21.11.2010, 15:02
    #36968208
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
sunhareСпасибо за ответы.
Уточню. Таблицы по типам действительно очень разные - в каждой будет более десятка уникальных для данного типа полей.
Есть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно.
Если уж Вы упорно не хотите хранить данные в одной таблице, что было бы оптимально, то хотя бы подумайте зачем Вам нужна таблица-"шапка".
...
Рейтинг: 0 / 0
21.11.2010, 15:15
    #36968219
sunhare
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
Если хранить данные в одной таблице, то она будет иметь более двухсот полей. Честно говоря, не знаю насколько это будет оптимально в плане производительности и занимаемого дискового пространства. СУБД PostgreSQL.
А таблица-шапка нужно просто для того, чтобы не дублировать в каждой таблице общие поля документов.
...
Рейтинг: 0 / 0
21.11.2010, 15:16
    #36968221
ПЕНСИОНЕРКА
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
БредятинаsunhareСпасибо за ответы.
Уточню. Таблицы по типам действительно очень разные - в каждой будет более десятка уникальных для данного типа полей.
Есть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно.
Если уж Вы упорно не хотите хранить данные в одной таблице, что было бы оптимально, то хотя бы подумайте зачем Вам нужна таблица-"шапка".

видимо типа журнал документов (1с)
...
Рейтинг: 0 / 0
21.11.2010, 15:35
    #36968242
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
ПЕНСИОНЕРКАвидимо типа журнал документов (1с)
Ну это Ваш ответ:)
Довольно патриотичный. Но у Вас всего две таблицы - это совсем другое решение, по которому тоже много вопросов, например, что значит "значение"? Строки, даты и числа в одной колонке?:)
И вообще, тогда уж нужно просто порекомендовать EAV.
...
Рейтинг: 0 / 0
21.11.2010, 15:48
    #36968261
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
sunhareЕсть сомнения по поводу производительности при выборке всех документов по какому-либо параметру.По параметру из общего набора будет быстро. По параметру, который есть только в конкретном типе документа - будет быстро, ведь ищется только в талице для этого типа.

sunhareЕсть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно.Ну уж конечно один-к-одному

БредятинаЕсли уж Вы упорно не хотите хранить данные в одной таблице, что было бы оптимально, то хотя бы подумайте зачем Вам нужна таблица-"шапка".Вот как раз для того, чтобы быстро искать и просматривать документы по общим полям.

Вполне нормальная и часто применяемая схема, особенно если большинство запросов касаются только общих полей (а так обычно и бывает).
...
Рейтинг: 0 / 0
21.11.2010, 16:00
    #36968277
sunhare
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
alexeyvg
sunhareЕсть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно.
Ну уж конечно один-к-одному
.

Это сарказм или утверждение? :)
...
Рейтинг: 0 / 0
21.11.2010, 16:16
    #36968297
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
sunharealexeyvgНу уж конечно один-к-одному.

Это сарказм или утверждение? :)Это сарказм по поводу того, как здесь можно применять связь многие-ко-многим :-)

Я и из первого поста понял, что речь шла о связи один-к-одному, хотя если внимательно прочитать, то видно, что это не так.
...
Рейтинг: 0 / 0
21.11.2010, 16:20
    #36968303
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
alexeyvgБредятинаЕсли уж Вы упорно не хотите хранить данные в одной таблице, что было бы оптимально, то хотя бы подумайте зачем Вам нужна таблица-"шапка".Вот как раз для того, чтобы быстро искать и просматривать документы по общим полям.
Вполне нормальная и часто применяемая схема, особенно если большинство запросов касаются только общих полей (а так обычно и бывает).
Это Вам она для этого нужна:) "особенно если" - это важный нюанс. В этом случае данные, тем более, нужно хранить в одной таблице.
...
Рейтинг: 0 / 0
21.11.2010, 16:21
    #36968305
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
sunharealexeyvgпропущено...

Ну уж конечно один-к-одному
.

Это сарказм или утверждение? :)
Это факт.
...
Рейтинг: 0 / 0
21.11.2010, 16:26
    #36968311
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
Бредятинаsunhareпропущено...


Это сарказм или утверждение? :)
Это факт.
Так всегда делают. Никто не утруждает себя поддержкой связи М:М для Вашего примера, хотя это и правильно было бы:)
...
Рейтинг: 0 / 0
21.11.2010, 16:28
    #36968314
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
БредятинаБредятинапропущено...

Это факт.
Так всегда делают. Никто не утруждает себя поддержкой связи М:М для Вашего примера, хотя это и правильно было бы:)
1:М, конечно:)
...
Рейтинг: 0 / 0
21.11.2010, 17:00
    #36968331
ViPRos
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
Бредятина,

М:М всегда правильно по определению :)
...
Рейтинг: 0 / 0
21.11.2010, 18:09
    #36968378
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
ViPRosБредятина,

М:М всегда правильно по определению :)
Даже 1:М имеет смысл только для одного из уже многих рассмотренных вариантов (в них уже запутаться можно:)), а уж М:М... Если только в том смысле, что для любой связи следует создавать отдельную таблицу.
...
Рейтинг: 0 / 0
23.11.2010, 14:14
    #36971956
Roman Slesarevsky
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
У меня была очень похожая задача и я применил точно такую же схему, как предлагает sunhare. У нас сейчас насчитывается около 40 разных типов документов. Тормозов при выборке не заметили. Вот только я отдельно вынес справочник типов документов (связан с основной таблицей документа связью 1:М).
...
Рейтинг: 0 / 0
23.11.2010, 15:46
    #36972185
Бредятина
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальная схема для множества документов
Roman SlesarevskyУ меня была очень похожая задача и я применил точно такую же схему, как предлагает sunhare. У нас сейчас насчитывается около 40 разных типов документов. Тормозов при выборке не заметили. Вот только я отдельно вынес справочник типов документов (связан с основной таблицей документа связью 1:М).
При выборке чего? Какие здесь могут быть тормоза?
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Оптимальная схема для множества документов / 21 сообщений из 21, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]