|
|
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Проблема в следующем. Бизнес-процесс разрабатываемого приложения подразумевает хранение документов нескольких типов. При этом у всех документов есть ряд общих полей - номер, дата, тип (ссылка на справочное значение), автор и ряд уникальных полей для каждого типа документа. Всего типов пока около 20-и, но в будущем возможно будет и больше. Пока идея по этому куску схемы данных следующая. Сделать отдельную таблицу для "шапки" (общие поля) документа и для каждого конкретного "тела" (уникальные поля) документа собственную таблицу, которая бы ссылалась на "шапку". Но эта схема кажется не очень красивой, тем более при возможном увеличении типов документа. Есть сомнения по поводу производительности при выборке всех документов по какому-либо параметру. Какие есть предложения и замечания? Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2010, 23:33 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
sunhare, сделайте одну таблицу, и никаких проблем у Вас не возникнет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 10:23 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
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--- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 11:20 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
sunhare, Идея у Вас нормальная. Если нужна скорость работы, то использовать вариант ПЕНСИОНЕРКИ не советовал бы. Что бы постоит таблицу с n-характеристиками нужно сделать n-Left join`ов, что будет тормозить процесс. Делать одну таблицу, если у Вас документы по типам очень разные - то же не вариант: To Бредятина: представьте как вы в одной таблице храните накладную и акт )))) а вот испоьлзование шапки (хотя здесь больше подходит понятие стержня, на который Вы как бы "нанизываете" ваши документы по ИД) вполне уместно. По-поводу увеличения типов документов то же не стоит беспокоиться... Если они у вас будут увеличиваться, то создавать талицы вам придется так и так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 13:20 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
lLocustДелать одну таблицу, если у Вас документы по типам очень разные - то же не вариант: To Бредятина: представьте как вы в одной таблице храните накладную и акт )))) а вот испоьлзование шапки (хотя здесь больше подходит понятие стержня, на который Вы как бы "нанизываете" ваши документы по ИД) вполне уместно. Мы вольно трактуем задачу, так как она не поставлена:) Что значит "очень разные"? Автор нигде не указал, что есть однородные "записи" в "документах". Конечно, все документы нужно хранить в одной "таблице". Не будет никаких проблем:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 13:36 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответы. Уточню. Таблицы по типам действительно очень разные - в каждой будет более десятка уникальных для данного типа полей. Есть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 14:06 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
sunhareСпасибо за ответы. Уточню. Таблицы по типам действительно очень разные - в каждой будет более десятка уникальных для данного типа полей. Есть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно. Если уж Вы упорно не хотите хранить данные в одной таблице, что было бы оптимально, то хотя бы подумайте зачем Вам нужна таблица-"шапка". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 15:02 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
Если хранить данные в одной таблице, то она будет иметь более двухсот полей. Честно говоря, не знаю насколько это будет оптимально в плане производительности и занимаемого дискового пространства. СУБД PostgreSQL. А таблица-шапка нужно просто для того, чтобы не дублировать в каждой таблице общие поля документов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 15:15 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
БредятинаsunhareСпасибо за ответы. Уточню. Таблицы по типам действительно очень разные - в каждой будет более десятка уникальных для данного типа полей. Есть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно. Если уж Вы упорно не хотите хранить данные в одной таблице, что было бы оптимально, то хотя бы подумайте зачем Вам нужна таблица-"шапка". видимо типа журнал документов (1с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 15:16 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
ПЕНСИОНЕРКАвидимо типа журнал документов (1с) Ну это Ваш ответ:) Довольно патриотичный. Но у Вас всего две таблицы - это совсем другое решение, по которому тоже много вопросов, например, что значит "значение"? Строки, даты и числа в одной колонке?:) И вообще, тогда уж нужно просто порекомендовать EAV. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 15:35 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
sunhareЕсть сомнения по поводу производительности при выборке всех документов по какому-либо параметру.По параметру из общего набора будет быстро. По параметру, который есть только в конкретном типе документа - будет быстро, ведь ищется только в талице для этого типа. sunhareЕсть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно.Ну уж конечно один-к-одному БредятинаЕсли уж Вы упорно не хотите хранить данные в одной таблице, что было бы оптимально, то хотя бы подумайте зачем Вам нужна таблица-"шапка".Вот как раз для того, чтобы быстро искать и просматривать документы по общим полям. Вполне нормальная и часто применяемая схема, особенно если большинство запросов касаются только общих полей (а так обычно и бывает). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 15:48 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
alexeyvg sunhareЕсть еще мысль: может между шапкой и телом документа есть смысл сделать наследование, т.е. связь один-к-одному, а не один-ко-многим как сейчас? Логически это, наверное, будет более правильно. Ну уж конечно один-к-одному . Это сарказм или утверждение? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 16:00 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
sunharealexeyvgНу уж конечно один-к-одному. Это сарказм или утверждение? :)Это сарказм по поводу того, как здесь можно применять связь многие-ко-многим :-) Я и из первого поста понял, что речь шла о связи один-к-одному, хотя если внимательно прочитать, то видно, что это не так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 16:16 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
alexeyvgБредятинаЕсли уж Вы упорно не хотите хранить данные в одной таблице, что было бы оптимально, то хотя бы подумайте зачем Вам нужна таблица-"шапка".Вот как раз для того, чтобы быстро искать и просматривать документы по общим полям. Вполне нормальная и часто применяемая схема, особенно если большинство запросов касаются только общих полей (а так обычно и бывает). Это Вам она для этого нужна:) "особенно если" - это важный нюанс. В этом случае данные, тем более, нужно хранить в одной таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 16:20 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
sunharealexeyvgпропущено... Ну уж конечно один-к-одному . Это сарказм или утверждение? :) Это факт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 16:21 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
Бредятинаsunhareпропущено... Это сарказм или утверждение? :) Это факт. Так всегда делают. Никто не утруждает себя поддержкой связи М:М для Вашего примера, хотя это и правильно было бы:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 16:26 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
БредятинаБредятинапропущено... Это факт. Так всегда делают. Никто не утруждает себя поддержкой связи М:М для Вашего примера, хотя это и правильно было бы:) 1:М, конечно:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 16:28 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
Бредятина, М:М всегда правильно по определению :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 17:00 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
ViPRosБредятина, М:М всегда правильно по определению :) Даже 1:М имеет смысл только для одного из уже многих рассмотренных вариантов (в них уже запутаться можно:)), а уж М:М... Если только в том смысле, что для любой связи следует создавать отдельную таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2010, 18:09 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
У меня была очень похожая задача и я применил точно такую же схему, как предлагает sunhare. У нас сейчас насчитывается около 40 разных типов документов. Тормозов при выборке не заметили. Вот только я отдельно вынес справочник типов документов (связан с основной таблицей документа связью 1:М). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2010, 14:14 |
|
||
|
Оптимальная схема для множества документов
|
|||
|---|---|---|---|
|
#18+
Roman SlesarevskyУ меня была очень похожая задача и я применил точно такую же схему, как предлагает sunhare. У нас сейчас насчитывается около 40 разных типов документов. Тормозов при выборке не заметили. Вот только я отдельно вынес справочник типов документов (связан с основной таблицей документа связью 1:М). При выборке чего? Какие здесь могут быть тормоза? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2010, 15:46 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36968378&tid=1542438]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
57ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 358ms |

| 0 / 0 |
