powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Что лучше: FK или триггеры проверки целостности?
25 сообщений из 63, страница 1 из 3
Что лучше: FK или триггеры проверки целостности?
    #39632855
V.Borzov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте,

Один умный человек говорил как-то, что чем создавать кучу FK на всё-всё-всё, лучше сделать кучу триггеров, проверяющих целостность ссылки. Я постеснялся спросить у него тогда, а чем это лучше. И с тех пор мучаюсь этим вопросом. Никак не могу понять, где потери, чем встроенный механизм проверок FK будет хуже, чем организация триггеров, которые будут делать, вроде бы, то же самое, но руками. Или умный человек был неправ?

Спасибо.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632863
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
V.Borzov, "умный" человек был неправ.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632868
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
V.Borzov,

умный человек неправ. Триггер действует на уровне пользовательской транзакции. Поэтому он не способен обеспечить контроль целостности между конкурирующими транзакциями (он тупо не видит чужих изменений).
А FK и PK проверяется по индексу, который содержит все ключи всех версий записей, т.е. он вне транзакций.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632883
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvV.Borzov,

умный человек неправ. Триггер действует на уровне пользовательской транзакции. Поэтому он не способен обеспечить контроль целостности между конкурирующими транзакциями (он тупо не видит чужих изменений).
А FK и PK проверяется по индексу, который содержит все ключи всех версий записей, т.е. он вне транзакций.

Вооот. А теперь представим себе мастер-таблицу, скажем, статусов документов. Нуусс, скажем, счетов.

Новый
В работе
Оплачен
Отгружено
Закрыт

И таблицу этих самых счетов. Из пары мильёнчиков документов хотя бы. FK от которой по статусу кивает на эту мастер-таблицу. Которая никогда и никем редактироваться не будет. И запросы с условием на статус в where. Которые подхватят этот самый индекс. Особенно ищущие закрытые, лет эдак через 10 функлицирования предприятия. И прикинем сизифовы усилия сервера на регулярном ресторе этой базы при создании этого самого индекса.

Жил один еврей, так он сказал, что всё относительно. Как говорят highly likely - it depends. Сдаёццо мне, что слова умного человека вырваны из контекста. Хотя в общем случае, безусловно, FK рулит.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632884
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А нефиг FK на 5 строк делать.

P.S. Топик не читал.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632886
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамА нефиг FK на 5 строк делать.

P.S. Топик не читал.


Если эти пять строк могут активно меняться - вполне так себе фиг. Правда лично я такой задачи придумать не могу :)
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632891
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вы, кстати, "универсальные" справочники практиковали?
Это когда несколько однотипных справочников
объединяются по вертикали - ID, Ref_ID, Value, ... ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632950
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Старый плюшевый мишкаА теперь представим себе мастер-таблицу, скажем, статусов документов. Нуусс, скажем, счетов.

Новый
В работе
Оплачен
Отгружено
Закрыт
NEW, IN_WORK, PAID, SHIPPED, CLOSED - ASCII символы этих слов слева направо легко умещаются в BIGINT от старшего байта к младшему, прекрасно сортируются и интерпретируются без всяких мастер-таблиц. Остается лишь прописать соответствующие числовые константы в ограничении CHECK соответствующего поля и создать по этому полю индекс.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632973
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамВы, кстати, "универсальные" справочники практиковали?
Это когда несколько однотипных справочников
объединяются по вертикали - ID, Ref_ID, Value, ... ?


Когда-то давно делали что-то похожее в мелком проекте. Чисто из интереса. Итог - закопали поглубже, ибо неудобно от слова совсем.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632976
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DarkMaster> неудобно от слова совсем.

А что именно было неудобно?
Разработка, сопровождение, иное?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632980
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамА что именно было неудобно?
Разработка, сопровождение, иное?Неудобно потому, что такой справочник лучше делать древовидным, когда первый уровень древа определяет тип справочника, а второй - элементы справочника. При использовании значений из такого справочника в поле таблицы придётся делать обвязку на триггере добавления/изменения. "Овчинка выделки не стоит".
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632991
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rdb_dev.... При использовании значений из такого справочника в поле таблицы придётся делать обвязку на триггере добавления/изменения. "Овчинка выделки не стоит".
о какой обвязке речь?
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632998
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
m7m, о такой, которая будет проверять - входит ли значение поля в соответствующий диапазон ключей, относящийся к конкретному типу справочника, т.е. проверять идентификатор узла соответствующего ключа.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39632999
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамDarkMaster> неудобно от слова совсем.

А что именно было неудобно?
Разработка, сопровождение, иное?


Ну то, что запросы становятся развесистыми - уже минус. Ну и постоянные кастование. Если честно - помню только общие нехорошие впечатления, но если очень интересно - могу покопаться в архивах - исходники где-то должны быть.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633002
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rdb_devГаджимурадов РустамА что именно было неудобно?
Разработка, сопровождение, иное?Неудобно потому, что такой справочник лучше делать древовидным, когда первый уровень древа определяет тип справочника, а второй - элементы справочника.

Есть такое дерево. Тоже задумывалось "для всего". Но в итоге там только справочник товаров, все остальное туда так и не засунул т.к. перестал понимать зачем.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633003
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У нас есть такой "универсальный" справочник. Вместо дерева используется идентификатор типа справочника. Проблема (у нас) в том, что в зависимости от этого типа нужна разная логика в поведении. Поэтому у нас она на клиенте. Допустим для одного справочника нужно каскадное удаление, для другого не нужно. Есть ещё проблемки. Например, просто пишем запрос по связанным справочникам и в запросе, допустим, 6-8 джойнов по одной таблице. Нечитаемо. И у меня есть подозрения в скорости таких запросов, хотя Влад сказал, что это вряд ли.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633028
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KreatorXXIНапример, просто пишем запрос по связанным справочникам и в запросе, допустим, 6-8 джойнов по одной таблице. Нечитаемо.

Через алиасы получается довольно читаемо.
Однако все равно не отвечает на вопрос - почему не в отдельных таблицах.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633044
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

Да
Но это были совсем простые справочники, фактически не имеющие никакой "расчетной" нагрузки, ну вроде вот такого
... здесь код, кто и когда создал запись, кто и когда последний раз её изменил
шифр
наименование
краткое наименование
....здесь еще несколько полей такого-же плана
примечание

И таки по факту для разработчиков это был "деревянный двухуровневый" справочник, для пользователей
это были полноценные отдельные справочники.
Из достоинств - очевидное при появлении нового "справочника" мизер телодвижений, добавить строку в первый уровень и в меню дабы он был доступен как отдельный справочник.

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

И собственно недостаток превысил достоинство

что касается именно "обвязки на триггере" - нам она была не нужна, ну просто из-за
придерживания "идеологии" - в "сырой документ" вводите всё что хотите и как хотите
а в обработку пойдет только тот документ в котором нет "ошибок", и проверка "на соответствие диапазону ключей" это та самое меньшее из контроля
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633060
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DarkMaster> Ну то, что запросы становятся развесистыми - уже минус.

Если мы говорим об одном и том же, то по сути добавляется только
одно (или два) условия в where (к одному/двум полям одной таблицы).
Не так уж и развесисто. С учетом нормальных алиасов как подсказали
выше - и читаемость особо не страдает.

> Ну и постоянные кастование.

Это ты про Value1, Value2 и пр. универсальные поля?

> Если честно - помню только общие нехорошие впечатления,

Меня интересуют впечатления, неизвестные грабли и пр,
исходники как раз малоинтересны, там сложностей нет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633064
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
m7m> Но это были совсем простые справочники, фактически
m7m> не имеющие никакой "расчетной" нагрузки

Ну я и говорю о простых справочниках, о которых выше речь
зашла, сложные-то понятно каждый в своей отдельной таблице.
Как справочник может иметь расчетную нагрузку не очень понял.

> Из недостатков - тоже очевидное,то что можно назвать "не додумал"
> (не полное знание предметной области, расширение круга решаемых задач)
>
> И собственно недостаток превысил достоинство

Ясно, спасибо. Иных недостатков, подводных камней не замечали?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633072
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамКак справочник может иметь расчетную нагрузку не очень понял.

Наверное я неправильно написал, имелось ввиду что-то в вроде вот такого
"коэффициент перерасчета из одной единицы измерения в другую", ну и тому подобное
Гаджимурадов РустамИных недостатков, подводных камней не замечали?
Нет, не вспоминается
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633074
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам С учетом нормальных алиасов как подсказали
выше - и читаемость особо не страдает.


Это когда их мало. Даже с альясами при "широкой" выборке запрос превращается в лес из JOIN`ов. Не удобно, потому что при возврате через месяц к этому запросу - нужно делать на лишнюю операцию больше, чтобы "раскрутить" запрос в голове и понять, куда какой справочник лепится.

Гаджимурадов Рустам> Ну и постоянные кастование.

Это ты про Value1, Value2 и пр. универсальные поля?


Про них.
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633086
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DarkMasterЭто когда их мало. Даже с альясами при "широкой" выборке запрос превращается в лес из JOIN`ов. Не удобно, потому что при возврате через месяц к этому запросу - нужно делать на лишнюю операцию больше, чтобы "раскрутить" запрос в голове и понять, куда какой справочник лепится.

Я немного не понял, ведь в любом случае независимо от того справочники в одной таблице или в разных "лес из JOIN`ов" останется, или я не прав?
...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633140
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамНу я и говорю о простых справочниках, о которых выше речь
зашла, сложные-то понятно каждый в своей отдельной таблице.
Как справочник может иметь расчетную нагрузку не очень понял.
Вот как-то так...
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
-- Не осуждайте за использование зарезервированных слов в именах доменов :)
CREATE DOMAIN SMALL_ID AS SMALLINT;
CREATE DOMAIN UNITAG AS VARCHAR(31) CHARACTER SET UTF8;
CREATE DOMAIN NAME AS VARCHAR(200) CHARACTER SET UTF8;

/*
 * --= Справочник размерностей =--
 * "id"       - Идентификатор размерности;
 * "main_id"  - Внешний ключ к идентификатору базовой размерности
 *              мастер-таблицы;
 * "base"     - Множитель базовой размерности;
 * "power"    - Степень множителя базовой размерности;
 * "mark"     - Метка размерности;
 * "name"     - Наименование размерности;
 */
CREATE TABLE "dims" (
    "id"      SMALL_ID NOT NULL,
    "main_id" SMALL_ID DEFAULT 0,
    "base"    INTEGER DEFAULT 10 NOT NULL,
    "power"   SMALLINT DEFAULT 0 NOT NULL,
    "mark"    UNITAG NOT NULL,
    "name"    NAME NOT NULL,
  CONSTRAINT "dims__pk" PRIMARY KEY ("id"),
  CONSTRAINT "dims__fk__self" FOREIGN KEY ("main_id")
    REFERENCES "dims" ("id") ON UPDATE CASCADE ON DELETE SET DEFAULT,
  CONSTRAINT "dims__uq" UNIQUE ("main_id", "base", "power", "mark")
);
COMMENT ON TABLE  "dims" IS 'Справочник размерностей величин';
COMMENT ON COLUMN "dims"."id" IS 'Идентификатор размерности';
COMMENT ON COLUMN "dims"."main_id"
  IS 'Ключ мастер-таблицы идентификатора базовой размерности';
COMMENT ON COLUMN "dims"."base"
  IS 'Множитель базовой размерности';
COMMENT ON COLUMN "dims"."power" IS 'Степень множителя базовой размерности';
COMMENT ON COLUMN "dims"."mark" IS 'Метка размерности';
COMMENT ON COLUMN "dims"."name" IS 'Наименование размерности';

REVOKE ALL ON TABLE "dims" FROM PUBLIC, ROLE USERS;
GRANT SELECT, REFERENCES("id") ON TABLE "dims" TO ROLE USERS;


CREATE GENERATOR "dims__GEN";
COMMIT WORK;


/*
 * Триггер получения идентификатора размерности величины
 * для новой записи
 */
SET TERM ^;
CREATE OR ALTER TRIGGER "dims__TR_BI"
  FOR "dims"
  ACTIVE
  BEFORE INSERT
  POSITION 0
AS
BEGIN
  IF (NOT(NEW."id" IS NOT NULL
      AND NEW."id" <= GEN_ID("dims__GEN", 0))) THEN
    NEW."id" = GEN_ID("dims__GEN", 1);
END^
SET TERM ;^
COMMIT WORK;

/*
SET TERM ^;
CREATE OR ALTER PROCEDURE oneRow
  RETURNS ("tmstmp" TIMESTAMP)
AS
BEGIN
  "tmstmp" = CURRENT_TIMESTAMP;
  SUSPEND;
END^
SET TERM ;^
GRANT EXECUTE ON PROCEDURE oneRow TO PUBLIC;
COMMIT WORK;
*/


DELETE FROM "dims";
SET GENERATOR "dims__GEN" TO 56;
INSERT INTO "dims"
    ("id", "main_id", "base", "power", "mark", "name")
        SELECT  0, NULL,   0,  0, '',    '' FROM oneRow
  UNION SELECT  1,    0,  10,  0, 'В',   'Вольт' FROM oneRow
  UNION SELECT  2,    1,  10,  3, 'кВ',  'Киловольт' FROM oneRow
  UNION SELECT  3,    1,  10,  6, 'МВ',  'Мегавольт' FROM oneRow
  UNION SELECT  4,    0,  10,  0, 'Ом',  'Ом' FROM oneRow
  UNION SELECT  5,    4,  10,  3, 'кОм', 'Килоом' FROM oneRow
  UNION SELECT  6,    0,  10,  0, 'А',   'Ампер' FROM oneRow
  UNION SELECT  7,    6,  10,  3, 'кА',  'Килоампер' FROM oneRow
  UNION SELECT  8,    0,  10,  0, 'Вт',  'Ватт' FROM oneRow
  UNION SELECT  9,    8,  10,  3, 'кВт', 'Киловатт' FROM oneRow
  UNION SELECT 10,    8,  10,  6, 'МВт', 'Мегаватт' FROM oneRow
  UNION SELECT 11,    8,  10,  9, 'ГВт', 'Гигаватт' FROM oneRow
  UNION SELECT 12,    0,  10,  0, 'Дж',  'Джоуль' FROM oneRow
  UNION SELECT 13,   12,  10,  3, 'кДж', 'Килоджоуль' FROM oneRow
  UNION SELECT 14,   12,  10,  6, 'МДж', 'Мегаджоуль' FROM oneRow
  UNION SELECT 15,    0,  10,  0, 'м',   'Метр' FROM oneRow
  UNION SELECT 16,   15,  10, -3, 'мм',  'Миллиметр' FROM oneRow
  UNION SELECT 17,   15,  10, -6, 'мкм', 'Микрометр' FROM oneRow
  UNION SELECT 18,   15,  10,  3, 'км',  'Километр' FROM oneRow
  UNION SELECT 19,    0,  10, -3, 'г',   'Грамм' FROM oneRow
  UNION SELECT 20,   19,  10, -6, 'мг',  'Миллиграмм' FROM oneRow
  UNION SELECT 21,   19,  10,  0, 'кг',  'Килограмм' FROM oneRow
  UNION SELECT 22,   19,  10,  3, 'т',   'Тонна' FROM oneRow
  UNION SELECT 23,    0,  60,  0, 'с',   'Секунда' FROM oneRow
  UNION SELECT 24,   23,  60,  1, 'мин', 'Минута' FROM oneRow
  UNION SELECT 25,   23,  60,  2, 'ч',   'Час' FROM oneRow
  UNION SELECT 26,   23, 86400,1, 'сут', 'Сутки' FROM oneRow
  UNION SELECT 27,   23,  10, -3, 'мс',  'Миллисекунда' FROM oneRow
  UNION SELECT 28,   23,  10, -6, 'мкс', 'Микросекунда' FROM oneRow
  UNION SELECT 29,    0,  10,  0, 'Гц',  'Герц' FROM oneRow
  UNION SELECT 30,   29,  10,  3, 'кГц', 'Килогерц' FROM oneRow
  UNION SELECT 31,   29,  10,  6, 'МГц', 'Мегагерц' FROM oneRow
  UNION SELECT 32,   29,  10,  9, 'ГГц', 'Гигагерц' FROM oneRow
  UNION SELECT 33,    0,   1,  0, '°C',  'Градус Цельсия' FROM oneRow
  UNION SELECT 34,    0,   1,  0, '°',   'Градус' FROM oneRow
  UNION SELECT 35,   34,  60, -1, '''',  'Угловая минута' FROM oneRow
  UNION SELECT 36,   34,  60, -2, '"',   'Угловая секунда' FROM oneRow
  UNION SELECT 37,    0,  10,  0, '%',   'Процент' FROM oneRow
  UNION SELECT 38,    0,  10,  0, 'Вар',  'Вар' FROM oneRow
  UNION SELECT 39,   38,  10,  3, 'кВар', 'Киловар' FROM oneRow
  UNION SELECT 40,   38,  10,  6, 'МВар', 'Мегавар' FROM oneRow
  UNION SELECT 41,   38,  10, -3, 'мВар', 'Милливар' FROM oneRow
  UNION SELECT 42,    0,  10,  0, 'ВА',   'Вольт-Ампер' FROM oneRow
  UNION SELECT 43,   42,  10,  3, 'кВА',  'Киловольт-Ампер' FROM oneRow
  UNION SELECT 44,   42,  10,  6, 'МВА',  'Мегавольт-Ампер' FROM oneRow
  UNION SELECT 45,   42,  10, -3, 'мВА',  'Милливольт-Ампер' FROM oneRow
  UNION SELECT 46,    0,  10,  0, 'раз',      'Раз' FROM oneRow
  UNION SELECT 47,   46,  10,  3, 'тыс.раз',  'Тысяч раз' FROM oneRow
  UNION SELECT 48,   46,  10,  6, 'млн.раз',  'Миллион раз' FROM oneRow
  UNION SELECT 49,   46,  10,  9, 'млрд.раз', 'Миллиард раз' FROM oneRow
  UNION SELECT 50,    0,  10,  0, 'шт.',      'Штук' FROM oneRow
  UNION SELECT 51,   50,  10,  3, 'тыс.шт.',  'Тысяч штук' FROM oneRow
  UNION SELECT 52,   50,  10,  6, 'млн.шт.',  'Миллион штук' FROM oneRow
  UNION SELECT 53,    0,  10,  0, 'бит/с',    'Бит в секунду' FROM oneRow
  UNION SELECT 54,   53,  10,  3, 'кбит/с',   'Килобит в секунду' FROM oneRow
  UNION SELECT 55,   53,  10,  6, 'Мбит/с',   'Мегабит в секунду' FROM oneRow
  UNION SELECT 56,    0,  10,  0, 'м/с',      'Метр в секунду' FROM oneRow;
COMMIT WORK;



/*
 * Представление долей размерностей по базовой размерности
 *
 * для отображения выбора долей величин измерений
 * и упрощения преобразований долей размерностей
 */
CREATE OR ALTER VIEW "dims__quotList"
AS
WITH RECURSIVE dims AS
(
  SELECT "main_id", "id", "base", "power",
      "mark" AS "main_mark", "mark", "name"
    FROM "dims"
    WHERE "main_id" = 0
  UNION ALL
  SELECT b."main_id", b."id", b."base", b."power",
      a."main_mark", b."mark", b."name"
    FROM "dims" b
      INNER JOIN dims a ON b."main_id" = a."id"
)
SELECT "main_id", "id", "base", "power", "main_mark", "mark", "name"
  FROM dims;


/*
 * Возвращает список долей величин по базовой размерности, отсортированный
 * по имени базовой размерности, базовому коэффициенту и его степени
 * относительно базовой размерности
 */
SET TERM ^;
CREATE OR ALTER PROCEDURE "dims__getQuotList"
  RETURNS
  (
    "id"      SMALL_ID,
    "name"    NAME
  )
AS
BEGIN
  FOR
      SELECT "id", "name"
        FROM "dims__quotList"
        ORDER BY "main_mark", "base", "power"
        INTO: "id", "name"
    DO
      SUSPEND;
END^
SET TERM ;^

GRANT SELECT ON "dims__quotList" TO PROCEDURE "dims__getList";
GRANT SELECT, REFERENCES ("id") ON TABLE "dims"
  TO PROCEDURE "dims__quotList";
COMMIT WORK;
/* ----------------------------------------------------------------- */

...
Рейтинг: 0 / 0
Что лучше: FK или триггеры проверки целостности?
    #39633152
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я вот приводил пример леса джойнов:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
select a.longname, b.longname, c.shortname, d.longname, e.longname, f.shortname
from sprav a
        inner join sprav b on b.id2=a.id and b.priznak=2
        inner join sprav c on c.id2=b.id and c.priznak=3
        inner join sprav d on d.id3=a.id2  and d.priznak=4
        inner join sprav e on e.id2=d.id and e.priznak=5
        inner join sprav f on f.id3=e.id and f.priznak=6
where a.priznak=1


Ну нечитаемо совсем. Если только комментарии к каждой строке...
...
Рейтинг: 0 / 0
25 сообщений из 63, страница 1 из 3
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Что лучше: FK или триггеры проверки целостности?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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