|
|
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Подскажите, кто знает, как решить следующую проблему: Cуществует таблица с данными, например TBL1. Она связана с справочниками STBL1, STBL2, STBL3... Связь TBL1->STBL1 = 1-ко многим, TBL1->STBL2 = 1-ко многим ... Но особенность ситуации заключается в следующем: каждай запись таблицы TBL1 связана ИЛИ c STBL1 ИЛИ с STBL2 ... Такой случай часто возникает, например, когда нужно бухгалерский журнал операций связать с различными справочниками. Вопрос состоит в следующем: ~~~~~~~~~~~~~~~~~~~ 1. Как правильно построить структуру БД для данного случая, в принципе, можно рассматривать несколько вариантов, но мне почему-то ни один не нравится :) 2. Как построить эффективный SELECT для вибора данных с таблиц TBL1, STBL1 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 18:39 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Одно и тоже поле связано в одной и той же таблице связано с несколькими справочниками? Т.е. выбор значения поля одно из значений хотя бы в одной справочной таблице? Я правильно понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 18:49 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
В принцыпе да. Но в вашем вопросе - содержится сразу и предложение определенной структуры (одного из вариантов) Но логически - именно так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 18:53 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Несколько сущностей например с двумя полями: ссылка на журнал операций и ссылка на требуемый справочник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:07 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Не совсем понятна ситуация когда это необходимо. На вскидку в журнал попадают счета и платежки и те и другие имеют разные структуры но должна попадать в одно и тоже поле идеологически правильно было бы создать общий тип "документ" и таблицу для него. И при работе с каждым типом документов открывать вьюхи. Однако это испортит производительность ввода документов. Второй вариант вешать триггер на обновление журнала и в нем разбирать является ли данное значение допустимым или нет. Программный форейн констрент. Ухудшает скорость внесения в журнал. Третьий вариант. Наплевать на непрерывную целостность данных и отлавливать некорректные строки через JOB. Это в принципе хорошо прокатывает только когда журнал и заполняется пакетными заданиями а не по пользовательскому произволу. По моему так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:08 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Но вообще это плохо. Самым правильным вариантом был бы один большой справочник в котором было бы всё, но бог велел делиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:10 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Браво ! (на счет общего справочника) Во многих случаях так и решают. Но это несколько сложно в случае если справочники имеют совершенно различние структуры (сущности), например: Люди Предприятия Материалы ... Именно так дела обстоят на практике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:20 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
А что это за поле где хранятся и люди и материалы и предприятия Я просто ТАКОГО представить не могу. Опиши бизнесс процесс. Может что придумать можно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:23 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Чем не устраивает предложенный мной вариант? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:24 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
2 MW Не как связать это просто. Длается поле указатель на соответсвующую сущность и через него коннектишся. Здесь все согласны. На это завязаны все возможные варианты. Другое дело где эту сущность хранить и как обрабатывать. Думаю имелось ввиду что-то вроде Junction Table но в данном случае от её наличия или отсутствия ничего не меняется. Грабли всё равно остаются. Или я чего не понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:28 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Приведу простой пример: Он хорошо известен разроботчикам различных учетных задач: cуществует "журнал операций" 1.Количество (Дебет, Кредит) 2.Сума (Дебет, Кредит) 3.Аналитика (Люди,Предприятия,Материалы и т.д) В эту таблицу попадают бухгалтерские проводки, которые формируются различными документами (чево-то типа таблицы фактов OLAP). Аналитика- это различные справочныки (в т.ч. многоуровнивые). Вот и весь бизнес-процесс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:31 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Тут все просто. Если я правильно понял проблема в подцеплении аналитического учета? В журнал операций добывляется код аналитики (1-материалы, 2 - персонал и т.п), и поле которое будет содержать значение аналитики (код из справочника никак не привязанный к нему, но это для ускорения, т.е. можно и не делать). Далее делается по промежуточной таблице для каждого справочника запись в этих таблицах содержит ссылку на строку журнала операций и на требуемую строку справочника. И заполняется триггером при вставке записи в журнал операций (отношение один к одному). Ведь выборки по разным аналитическим данным _обычно_ не делаются. В данном случае выборку по журналу операций указав код аналитического учета сделать очень просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:38 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Тогад MW наверное прав 1) Сделать Junction TABLE в ней хранить все возможные типы аналитики много строк, мало собственно информации. 2) заполнять Junction TABLE пакетным заданием из нормальных справочников 3) и классический FK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:38 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Наверное я или немогу описать проблему или она действительно неразрешима ???? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:40 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Последний раз мы с MW поняли тебя одинаково. Задача красиво действительно неразрешима. Но решение работающее вполне есть см выше. Чем не устраивают предложенные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:44 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>> Eter Panji Еще раз браво ! Это очень близко к решению, к которому я пришел. Но я извеняють за невежество, что такое Junction TABLE ? Как сопровождать Junction TABLE ? Триггерами ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:45 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
"Ключевая фраза": Промежуточная таблица не одна а несколько: MAINBOOK( ID, VID) -- журнал операций VID = 1 для персонала, =2 для материалов LINK_PERSONAL( PERSONAL_ID, MAINBOOK_ID) LINK_MATERIAL( MATERIAL_ID, MAINBOOK_ID) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:46 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
в данном случае JUNCTION TABLE - журнал всех типов аналитики Если исходные таблицы-справочники заполняются редко то самое лучшее поставить JOB который с какой-то периодичностью будет синхронизировать справочники и JUNCTION TABLE Если часто тогда действительно лучше триггерами на справочниках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:49 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
А зачем несколько? Выигрыш будет небольшой, или ... это получится отношение многие ко многим? А зачем оно вообще нужно в данном контексте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:51 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>All Спасибо огромное ! Мне действительно некоторые вещи стали более понятны. В особенности, у меня исчезно какоето-болезненное впечатление, что я никак не могу просто и эффективно (без промежуточных таблиц ) решить это проблему. На самом деле, наверное действително так ее решить невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 19:53 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
А невозможно разные сущности свести к одной ссылке, нарушается целостность данных. И скажите мне в каких случаях может потребоватся запрос на одновременный вывод данных по разным видам аналитического учета? И даже в этом случае можно выйти из положения по предложенной схеме. И не требуется никаких обновлений. Отношение один к одному, вставка в промежуточную таблицу при сохранении документа и создании записи в журнале операций, ведь заранее известно какой документ какие виды аналитики на себе несет. А если схема данных организована еще грамотнее (на полупроводках), то это еще снимет массу головной боли в последствии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:07 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
>И скажите мне в каких случаях может потребоватся запрос на >одновременный вывод данных по разным видам аналитического учета? Просто вывести на экран (отчет) журнал операций. И все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:13 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Там требуется вывод аналитики? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:14 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
В принципе, да. Т не только там. То же самое - любой бухгалтерский документ: например, акт о приеме материалов - там тоже присутствует аналитика. И когда необходимо высести "журнал документов", в нем есть поле : от кого получено, кому передано и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:18 |
|
||
|
SELECT : вопрос к гуру :)
|
|||
|---|---|---|---|
|
#18+
Да не вопрос: select m.id, m.vid, m.summa, mt.name from mainbook m, link_material lm, material mt where m.id = lm.mainbook_id and m.vid = 1 and lm.material_id = mt.id union select m.id, m.vid, m.summa, p.name from mainbook m, link_personal lp, personal p where m.id = lp.mainbook_id and m.vid = 2 and lp.personal_id = p.id union и т.п ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 20:23 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32147180&tid=1990730]: |
0ms |
get settings: |
10ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
164ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
85ms |
get tp. blocked users: |
1ms |
| others: | 273ms |
| total: | 565ms |

| 0 / 0 |
