|
|
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
Всем, привет. В наличии TableMain (id integer, ref1_id, ref2_id) TableRef1(id integer, name varchar(10)) TableRef2(id integer, name varchar(10)) Что лучше: a) Create view ... as Select tm.id, tm.ref1_id, tr1.name, tm.ref2_id, tr2.name from TableMain tm left join TableRef1 tr1 on tm.ref1_id=tr1.id left join TableRef2 tr2 on tm.ref2_id=tr2.id и работать с view или b) alter table TableMain add ref1_name computed by (select tr1.name from TableRef1 tr1 where tr1.id=ref1_id) alter table TableMain add ref2_name computed by (select tr2.name from TableRef2 tr2 where tr2.id=ref2_id) и работать с таблицей или с) писать связующие запросы на клиенте ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 12:59 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
Я бы использовал способ с. Способ б не рекомендуется, когда-то я даже знал, почему, но забыл :-((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 13:02 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
Способ "б" однозначно не использовать Есть еще варианты d) create procedure ... for Select tm.id, tm.ref1_id, tr1.name, tm.ref2_id, tr2.name from TableMain tm left join TableRef1 tr1 on tm.ref1_id=tr1.id left join TableRef2 tr2 on tm.ref2_id=tr2.id into :id, :ref1_id, :ref1_name, :ref2_name do suspend; e) Select tm.id, tm.ref1_id, tr1.name, tm.ref2_id, tr2.name from TableMain tm left join TableRef1 tr1 on tm.ref1_id=tr1.id left join TableRef2 tr2 on tm.ref2_id=tr2.id И кстати почему left join? Таблицы не связаны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 15:13 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
2 Denis Uskov: left join т.к. м.б. null в главной таблице ХП совсем не нравится, т.к. если не писать на клиенте весь запрос, то хотелось бы иметь возможность использовать результат как отношение, а с ХП там то ли какие-то ограничения, то ли план не оптимален получается Еще один вопрос всем. Верно ли следующее: при создании view, компилируется его код, включая план запроса, и даже если впоследствии, например, добавить в базу индекс, то View его использовать не будет, пока не сделаешь drop-create. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 16:18 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
Вроде как план не должен компилиться. Ты возьми и проверь и нам расскажи. Я бы и сам поверил, да зянят очень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 16:40 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
Попробовал. Не верно. 2 Gold: Спасибо за совет ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 17:21 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
О, вот видишь, сколько пользы! Боле того, старые версии сервера допускали при создании представления явно указывать план запроса, так этот план вобще игнорируется, если мне память не изменяет, и индексы используются в зависимости от контекста, в котором это представление использовано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 17:27 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
Жаль только, что в случае a) если TableRef1.id - primary (а значит и unique) key и учитывая объединение по left join во View, запрос вида: select v.TableMain_id from OurView v все равно заставит сервер читать записи в таблице TableRef1 и проиграет запросу select id from TableMain И не задумывался бы я больше над тем остановиться на варианте a (облегчив жизнь прикладникам) или на c (заставив их самих писать Query.SelectSQL и выигрывая в производительности за счет "штучности", а значит и оптимальности запросов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 17:58 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
Может быть не совсем в тему, но я в таких случаях часто использую несколько экзотический и, возможно спорный способ. Так что попрошу сразу ногами не бить!!! 1) alter table TableMain add ref1_name varchar(30) - не Computed, а самое обычное!!! 2) Привязываем ref1Id,ref1_Name при помощи внешнего ключа c Update-action к Table_Ref1 3) При изменении записи организую работу со справочником средствами приложения. То есть в таблице ФИЗИЧЕСКИ имеется поле результатата, инициализирующееся при изменении данных (Pre-Computed). Целостность данных обеспечивается как сервером (через Referential Integrity), так и клиентом (на этапе изменения записей). Упрощаются (и ускоряются) соответствующие выборки. Правда усложняются (и замедляются) процессы изменение данных и вырастает объем базы. Способ этот я выдумал не сам, а позаимствовал из одно промышленной системы. Там, как я думаю, он применялся именно для ускорения выборок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2003, 10:01 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
koff4 Может я чего не понимаю, но зачем тогда ref1_id в главной таблице и id в подчиненной? Не достаточно ли просто ref1_name и name соответственно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2003, 12:28 |
|
||
|
Связка со справочником: View, Computed By или на клиенте?
|
|||
|---|---|---|---|
|
#18+
To Accue: ref1_id и id используются при контроле ссылочной целостности (CASCADE UPDATE). То есть если в tableRef1 изменить name - тут же изменятся соответствующие значения ref1_name в Table_main. Хотя, если name является одновременно является первичным ключом, тогда ты прав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2003, 12:09 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=32261532&tid=1579976]: |
0ms |
get settings: |
9ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
178ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
2ms |
| others: | 236ms |
| total: | 484ms |

| 0 / 0 |
