Здравствуйте, kallisto, Вы писали:
K>Здравствуйте, pkarklin, Вы писали:
P>>Интереснаа логика, однако...
K>Это не логика, это практика. Не частая, но имеющая место быть.
Ну, давайте будем меряться, у кого "практика" больше...
P>>1. Зачем мне проверять "родителя", если это за меня гараздо эффективнее зделает FK?
K>И что, вы предлагаете каждый раз ловить ексепшен работы констреинта, если при вставке не было найдено родителя, нежели один раз написать, например, запрос со связанной переменной и просто биндить новое значение id_родителя (прошу не забывать, что речь идёт не о 10-ке таблиц с сотней строк каждая, и не о единичной вставке)
Один раз, говорите... Вот так вот у Вас в системе не из "10-ка таблиц с сотней строк в каждой" все решается "одним запросом, биндящем значение родителя"?! Я, конечно, не Станиславский, но опять же из "практики" скажу: "Не верю"! Когда в системе к таблице идет обращение из не одной сотни хп, то для меня другого пути поддержки целостности (Domain Integrity), как использования CHECK или FK, нет. И каким бы гением не был разработчик он не даст 100% гарантии, что он в коде, где идет обращение к этой таблице не забыл "пробиндить родителя" тем или иным способом.
P>>2. Зачем мне в триггере проверять валидность значения поля, если это за меня гараздо эффективнее сделает CHECK.
K>Никто не говорил про проверку значений в триггере
Тогда что Вы имели ввиду, когда говорили "отказались от триггеров"? Что Вы в них делали? И куда перенесли заложенную в них логику, когда от них отказались...
P>>Если Вы идете речь о том, что Вам надо не просто проверить валидности значения поля, но еще и в случаи нарушения валидности выдать "на гора" "человеческое сообщение об ошибке" и вы это реализовали в коде, то да, CHECK, как объект можно вроде бы не вешать! Тоже самое касается и других ограничений. Но тут остается лазейка для dbo.
K>Какая?
Прямой доступ к таблицам!
P>>Причем, так сказать, он по своей невнимательности может
K>Кто?
Человек, имющий соответсвующие права... И не надо в 1 000 раз говорить мне (а то опять у меня будет дежавю), что "админов, лазающих в базу руками надо расстреливать"... Опять же скажу из опыта, что даже в работающей продакшен системе бывают случаи, когда такое вмешательство необходимо. Кроме того, такое вмешательсвто может быть и случайным.
P>>обойти закодированные ограничения и нарваться на рассогласованность данных. И никаких напоминаний типа "Запрещается лезьт в базу руками" не хватит.
K>Прошу не забывать, что речь идёт не о системе бухучёта. Вставка "руками" не выполняется вообще. Имеется одна подсистема, которая процессит данные в базе и есть другая подсистема, которая эти данные в базу скаладывает собирая их перед этим с CDR. Всё происходит без участия человека. О каких лазейках идёт речь?
Хм... Можно подумать, что "в системе Бухучета" вставка выполняетс руками?! И, смотрю, мы уже перешли на обсуждение какой-то конкртеной системы, а не обсуждаем общие подходы. Вы готовы дать 100% гарантии, что эти обе подсистемы не имеют ошибок, заложенных в коде? Т.е. когда возникает ситуация, не проверенная на этапе тестирования? И при отсутствии декларативной целостности данных мы получим их рассогласованность.
P>>И что для Вас будет важно? Быстродействие — или быстродействие + консистентность данных. Я бы 10 раз подумал... Для повышения быстродействия можно найти другоие способы
K>Это демагогия. Способы в студию — нам чужой опыт только в плюс пойдёт!
Нет, это не демагогия. Снос поддержки декларативной целостности данных — это "фол последней надежды". Тюнить надо начинать не с этого. И не надо забывать про железо...
Здравствуйте, pkarklin, Вы писали:
P>Когда в системе к таблице идет обращение из не одной сотни хп, то для меня другого пути поддержки целостности (Domain Integrity), как использования CHECK или FK, нет.
Если рассматривать не просто обращение, а модификацию таблицы, но это неправильно на мой взгляд. Модификация данных в идеале разрешена только через один API, где и сосредоточены все необходимые проверки. А если мы гарантируем, что любая штатная операция происходит только через данный API (ручное вмешательство пока не рассматрваем), то у нас появляется выбор: реализовать проверку в ХП, в триггере или в констрейнте. Реализация в ХП дает нам гибкость, которую нельзя получить иначе. Пример: надо изменить большой объем данных, которые заведомо валидны (например выбраны из той же или другой такой же таблицы). Имея констрейнты, мы не можем временно их отключить, эффективно выполнить все DML операции, а потом включить снова. (С триггерами, правда, подобные фокусы иногда возможны .) Реализуя проверки в коде, мы можем избежать лишней работы, а значит повысить производительность. Далее, представьте себе, что правила целостности изменились (в соответствии с бизнес-правилами). Что проще и дешевле изменить, констрейнты или код? Возьмем еще более сложный случай: правила изменились, но остались терабайты накопленных данных, с которыми надо работать по старым правилам (система версионная). А с новыми — по новым. Как будут выглядеть констрейнты в этом случае?
Теперь о проблеме ручного вмешательства. Констрейнт на самом деле от него не спасает, потому что админ может его отключить, если он считает себя умнее всех. А если не считает, то и не станет трогать данные, не посоветовавшись с разработчиками или техподдержкой.
P>Снос поддержки декларативной целостности данных — это "фол последней надежды". Тюнить надо начинать не с этого. И не надо забывать про железо...
Ну вроде же объяснили, что с этого не начинают, этим заканчивают.
Вообще странно видеть такой бурный общественный протест против неиспользования DRI, ведь это всего лишь один из подходов, дополнительный сервис, предоставляемый СУБД. Выбор тут также неоднозначен, как и с нормализацией-денормализацией. И в умных книжках вроде пишут, что целостность данных может обеспечиваться как на системном, так и на прикладном уровне.
W>Если рассматривать не просто обращение, а модификацию таблицы, но это неправильно на мой взгляд. Модификация данных в идеале разрешена только через один API, где и сосредоточены все необходимые проверки. А если мы гарантируем, что любая штатная операция происходит только через данный API (ручное вмешательство пока не рассматрваем), то у нас появляется выбор: реализовать проверку в ХП, в триггере или в констрейнте. Реализация в ХП дает нам гибкость, которую нельзя получить иначе. Пример: надо изменить большой объем данных, которые заведомо валидны (например выбраны из той же или другой такой же таблицы). Имея констрейнты, мы не можем временно их отключить, эффективно выполнить все DML операции, а потом включить снова. (С триггерами, правда, подобные фокусы иногда возможны .)
В MS SQL Server мы как раз это можем:
ALTER TABLE ... CHECK | NOCHECK CONSTRAINT { ALL | constraint_name [ ,...n ] }
Более того, можно наложить новые ограничения на таблицу с существующими данными, которые не подпадают под эти новые ограничения.
ALTER TABLE ... ADD CONSTRAINT ... WITH CHECK | WITH NOCHECK CONSTRAINT { ALL | constraint_name [ ,...n ] }
W>Реализуя проверки в коде, мы можем избежать лишней работы, а значит повысить производительность.
Любая проверка в коде будет медленне предназначенных для этого средств сервера. Проверено!
W>Далее, представьте себе, что правила целостности изменились (в соответствии с бизнес-правилами). Что проще и дешевле изменить, констрейнты или код? Возьмем еще более сложный случай: правила изменились, но остались терабайты накопленных данных, с которыми надо работать по старым правилам (система версионная). А с новыми — по новым. Как будут выглядеть констрейнты в этом случае?
А вот здесь надо подходить в каждом конкретном случаи индивидуально. В некоторых случаях можно опять-таки обойтись стандартным функционалом декларативной целостности (например в виде CHECK использовать UDF, или использовать секционирование для таблиц с "новыми"\"старыми" правилами.), а в некоторых случаях неизбежно придеться от таковых отказаться.
W>Теперь о проблеме ручного вмешательства. Констрейнт на самом деле от него не спасает, потому что админ может его отключить, если он считает себя умнее всех. А если не считает, то и не станет трогать данные, не посоветовавшись с разработчиками или техподдержкой.
Согласить, что операция отключения ограничении делается более осмысленно, чем попытка удалить записи из таблицы со стороны 1 в отношении 1->М.
P>>Снос поддержки декларативной целостности данных — это "фол последней надежды". Тюнить надо начинать не с этого. И не надо забывать про железо... W>Ну вроде же объяснили, что с этого не начинают, этим заканчивают.
Согласен.
W>Вообще странно видеть такой бурный общественный протест против неиспользования DRI, ведь это всего лишь один из подходов, дополнительный сервис, предоставляемый СУБД. Выбор тут также неоднозначен, как и с нормализацией-денормализацией. И в умных книжках вроде пишут, что целостность данных может обеспечиваться как на системном, так и на прикладном уровне.
Мой "бурный протест" протест был вызван слишком категоричными заявлениями о "вреде использовании декларативной целостности". А так, я с Вами абсолютно согласен, что все должно быть сбалансировано.
Здравствуйте, pkarklin, Вы писали:
P>Вы знаете, мне трудно понять что Вы имели ввиду. Можно на пальцах объяснить Вашу мысль... Или, как сказано в х\ф Москва слезам не верит: "Переведи..."
Хм., дело вот в чем, что с теми провайдерами сотовой связи в которых (с которыми) мне приходилось иметь дело никогда(!) не использовали FK в таблицах общета абонентов, по причине нецелесообразности. Зачем? Вы все-равно не заметите, что вместо 56секунд разговора, модули ядра билиннга системы вас посчитали 2 раза по 56секунд, просто потому, что сотрудник компании запустил неумышленно модуль общета абон. базы. И это только один пример, а сколько еще багов дают нам NE, roaming, prepaid...
Вобщем, если вы разрабатывали (или видели как разрабатывают) системы масштаба национального оператора вы меня поймете
Здравствуйте, 0rc, Вы писали:
0rc>Хм., дело вот в чем, что с теми провайдерами сотовой связи в которых (с которыми) мне приходилось иметь дело никогда(!) не использовали FK в таблицах общета абонентов, по причине нецелесообразности. Зачем? Вы все-равно не заметите, что вместо 56секунд разговора, модули ядра билиннга системы вас посчитали 2 раза по 56секунд, просто потому, что сотрудник компании запустил неумышленно модуль общета абон. базы. И это только один пример, а сколько еще багов дают нам NE, roaming, prepaid... 0rc>Вобщем, если вы разрабатывали (или видели как разрабатывают) системы масштаба национального оператора вы меня поймете
В моем понимании любая система должна обеспечивать максимально возможную целостность данных. В не зависмости от того, каков будет предполагаемый процент обращений клиентов с жалобами.
Ну, а то, что существующие биллинговые системы далеки от этого, то это можно отнести только на совесть их разработчиков. IMHO.
Здравствуйте, 0rc, Вы писали:
0rc>Здравствуйте, pkarklin, Вы писали:
0rc>Существующие биллинговые системы далеки от этого, то это можно отнести только на опыт их разработчиков. IMHO.
Ну, что ж, каждый из нас, на сколько я понимаю, все равно останется при своем IMHO.
Здравствуйте, Merle, Вы писали:
M>Ребята, если вам удалось довести базу до того, что самое узкое место в ней это check констрейнты — снимаю шляпу. M>В другом месте тюнить не пробовали? M>Плюс не забывайте, что, как правило, грамотно спректированая база работает с FK и прочими констрейнтами шустрее чем без них, в силу того, что подобные вещи в некоторых случаях являются довольно существенными подсказками оптимизатору.
Про правильно спроектированную базу никто не говорил так сказать "дарёному коню в зубы заглядать не дают". Шо имеем, на том и работаем.
Система уже давно в продакшене, да и абонентская база более 14 млн, вот только текущая схема не для такого количества данных. А на "том конце" ещё не созрели на её переработку. Заказчик решил, что купить новое железо+solaris будет дешевле, чем перелопатить всю структуру с импортом имеющихся данных.
Вот и дали немного исходники подправить и одним пальцем базу поковырять.
И, смотрю, мы уже перешли на обсуждение какой-то конкртеной системы, а не обсуждаем общие подходы. Вы готовы дать 100% гарантии, что эти обе подсистемы не имеют ошибок, заложенных в коде? Т.е. когда возникает ситуация, не проверенная на этапе тестирования? И при отсутствии декларативной целостности данных мы получим их рассогласованность. 
.) Реализуя проверки в коде, мы можем избежать лишней работы, а значит повысить производительность. Далее, представьте себе, что правила целостности изменились (в соответствии с бизнес-правилами). Что проще и дешевле изменить, констрейнты или код? Возьмем еще более сложный случай: правила изменились, но остались терабайты накопленных данных, с которыми надо работать по старым правилам (система версионная). А с новыми — по новым. Как будут выглядеть констрейнты в этом случае?
