SQL: Размышления о хаосе и порядке.

← →
Kostafey © (2009-10-18 23:14) [0]

Вот ваяются запросы, сложность их бывает довольно высока,
а я вот вдруг подумал, что это все слишком ненадежно.
Все это слишком зависит от текущего наполнения БД.

Вот простой пример:
select SomeThing from SomeTable inner join SomeDictionary on SomeDictionary.key = SomeTable.FK_key where SomeDictionary.key = 1 -- Некоторое значение

Но стоит поменять ключ у "Некоторое значение" на 2 и все рухнет.
Запрос будет возвращать не то что нужно.

Использовать текстовые значения - не намного лучше:
select SomeThing from SomeTable inner join SomeDictionary on SomeDictionary.key = SomeTable.FK_key where SomeDictionary.value = "Некоторое значение"

Стоит "Некоторое значение" поменять на "Другое значение" и все.

А ведь нельзя запретить пользователям редактировать справочники.
Бить по рукам за неверные движения?

Причем выяснить что именно произошло не так просто.
Запрос просто перестал работать как надо. А почему?
(В оригинале это звучит: "А программа не работает!")
Пойди разберись сам.
Всех значений всех справочников не упомнишь.

Как бороться с перманентной изменяемостью БД?
Есть какие-то мысли по этому поводу?

P.S. Я параноик? :)

← →
DVM © (2009-10-18 23:22) [1]

> Бить по рукам за неверные движения?

Записывать кто что когда отредактировал.

← →
Kostafey © (2009-10-18 23:27) [2]

> [1] DVM © (18.10.09 23:22)
> Записывать кто что когда отредактировал.

Вести отдельный лог действий пользователей по
корректировке справочников?
Гениально! Да, это хорошая идея.

← →
Игорь Шевченко © (2009-10-18 23:45) [3]

> Всех значений всех справочников не упомнишь.

А оно тебе надо ?

Какой-то странный справочник - допускаются "некоторое значение" и "другое значение" - это два значения чем-то по физическому смыслу отличаются в прикладной области задачи ?

← →
Kostafey © (2009-10-18 23:53) [4]

> А оно тебе надо ?

"Кто, если не мы" (с)

> Какой-то странный справочник - допускаются "некоторое значение"
> и "другое значение" - это два значения чем-то по физическому
> смыслу отличаются в прикладной области задачи ?

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

← →
Игорь Шевченко © (2009-10-18 23:58) [5]

Я другое имею в виду - если ты делаешь join, то по здравому смыслу первичному ключу в таблице справочника должен соответствовать внешний ключ таблицы с данными и целостность этого соответствия должна поддерживать СУБД.

← →
Игорь Шевченко © (2009-10-18 23:59) [6]

А в целом я несильно понимаю задачу - если это отголоски темы
http://delphimaster.net/view/15-1255696143/, то там вроде сказали, что бардак не автоматизируется и размышления о вечном к бардаку неприменимы.

← →
Kostafey © (2009-10-19 00:06) [7]

> [5] Игорь Шевченко © (18.10.09 23:58)

Конечно, но справочник, тем не менее, можно
модифицировать сохранив целостность.
Например, содержимое справочника:
1 - черное
2 - белое
Достаточно поменять текст местами.

Кажется притянутым за уши? Не-а. :)
Справочник действительно можно "переработать",
обновив ряд наименований, скорректировав
смысл некоторых из них...

Еще возможен случай, когда запрос пишется под
готовый стправочник, но пустую таблицу с данными.
Тут уж полная свобода модификаций! :)

← →
Kostafey © (2009-10-19 00:10) [8]

> [6] Игорь Шевченко © (18.10.09 23:59)

Скорее так: текушая тема и тема по приведенной
ссылке - отголоски одной и той же задачи. :)

Но давайте посмотрим на текущую тему независимо от
предыдущей, вне ее контекста.

Ведь это логичная ситуация.
Пользователи могут корректировать справочники -
это потенциальная (и реальная) угроза логике
запросов.

← →
Игорь Шевченко © (2009-10-19 00:31) [9]

Kostafey © (19.10.09 00:10) [8]

> Ведь это логичная ситуация.
> Пользователи могут корректировать справочники -
> это потенциальная (и реальная) угроза логике
> запросов.

Если записи в справочниках корректируют, значит это кому-то нужно.

Я не совсем понимаю угрозы логике запросов (и каких запросов?)

> Вот простой пример:
> select SomeThing
> from SomeTable
> inner join SomeDictionary on SomeDictionary.key = SomeTable.
> FK_key
> where SomeDictionary.key = 1 -- Некоторое значение
>
> Но стоит поменять ключ у "Некоторое значение" на 2 и все
> рухнет.

, если честно.

А что, так легко поменять ключ у SomeDictionary.key при включенных ограничениях ссылочной целостности ?

Я полагаю, не очень легко (впрочем, смотря что за СУБД) - в Oracle так сделать невозможно.

← →
sniknik © (2009-10-19 01:24) [10]

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

← →
qwer_qwer (2009-10-19 01:39) [11]

> select SomeThing from SomeTableinner join SomeDictionary
> on SomeDictionary.key = SomeTable.FK_keywhere SomeDictionary.
> key = 1 -- Некоторое значение

Ты считаешь, что в условии key=1 это правильный метод?

← →
qwer_qwer (2009-10-19 01:42) [12]

Вообще, исходя их твоих требований, решение простое и во многих базах оно давно и успешно используется.

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

← →
qwer_qwer (2009-10-19 01:43) [13]

> Вот ваяются запросы, сложность их бывает довольно высока,

Как раз потому такие запросы, в которых константы, не надо использовать.
Кроме того, должны быть справочники, которые пользователь не имеет права исправлять вообще.

> qwer_qwer (19.10.09 01:42) [12]
> Вообще, исходя их твоих требований, решение простое и во
> многих базах оно давно и успешно используется.
> Вводится справочник справочников и все связки осуществляются
> только через ключи из этого справочника,
а дальше при составлении справочников информационные маски, типа если не белое, то черное..(выбор).

SQL: Размышления о хаосе и порядке. Найти похожие ветки