powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Оптимальная схема для множества документов
21 сообщений из 21, страница 1 из 1
Оптимальная схема для множества документов
    #36967817
sunhare
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте. Проблема в следующем. Бизнес-процесс разрабатываемого приложения подразумевает хранение документов нескольких типов. При этом у всех документов есть ряд общих полей - номер, дата, тип (ссылка на справочное значение), автор и ряд уникальных полей для каждого типа документа. Всего типов пока около 20-и, но в будущем возможно будет и больше.
Пока идея по этому куску схемы данных следующая. Сделать отдельную таблицу для "шапки" (общие поля) документа и для каждого конкретного "тела" (уникальные поля) документа собственную таблицу, которая бы ссылалась на "шапку".
Но эта схема кажется не очень красивой, тем более при возможном увеличении типов документа. Есть сомнения по поводу производительности при выборке всех документов по какому-либо параметру.
Какие есть предложения и замечания?
Заранее спасибо.
...
Рейтинг: 0 / 0
Оптимальная схема для множества документов
    #36967961
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sunhare,
сделайте одну таблицу, и никаких проблем у Вас не возникнет
...
Рейтинг: 0 / 0
Оптимальная схема для множества документов
    #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
Оптимальная схема для множества документов
    #36968131
Фотография lLocust
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sunhare,

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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