Re[13]: Хранимые процедуры и их использование - Базы данных

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Расскажите как Вы используете ХП?

А>с использованием ХП — с ними гораздо проще, да и правильней рулить правами

Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
Причем в 2 из них придется передавать 30 параметров.
Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

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

А>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Аноним, Вы писали:

А>>>Расскажите как Вы используете ХП?

А>>с использованием ХП — с ними гораздо проще, да и правильней рулить правами

А>Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
А>Причем в 2 из них придется передавать 30 параметров.
А>Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А>А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

А>Потом добавляется одно поле. Надо поменять процедуру, надо в форме сделать во всех местах присвоение параметров. В общем на мой взгляд это не проще ...

А>>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

А>И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

Вообще то речь в цитируемом посте шла об управлении безопасностью.

А насчет необходимости добавления одного поля в процессе эксплуатации... так это надо гнать с работы таких архитекторов и аналитьиков, ИМХО.

Здравствуйте, Аноним, Вы писали:

А>Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
А>Причем в 2 из них придется передавать 30 параметров.
А>Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А>А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

А>Потом добавляется одно поле. Надо поменять процедуру, надо в форме сделать во всех местах присвоение параметров. В общем на мой взгляд это не проще ...

А>>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

А>И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

Ну, канечно, проще с TADOQuery.

Особенно если все запихано в одну таблицу. А вот представьте себе, когда структуру данных нормализована по самое не хочу и то, что пользователь вводит в 30 контролов на форме распихивается в 10 таблиц в бд. Как вы тут одним TADOQuery выкрутитесь? Да и кроме простых операций по изменения данных, обычно в хп закладывают бизнес логику. При этом доступа к таблицам вообще нет. И вся работа организуется через Вызов соответсвующих хп.

Другой аспект. Предположим, что Вы работаете непосредственно с таблицами (представлениями) с клиента, т.е. с явно зашитыми в клиента инструкциями по модификации данных. А теперь представьте себе, что возникла необходимость в изменении структуры хранения или алгоритма обработки. И мы лезем в проект, правим там, компилируем и ... теперь нам надо все это обновить у пользователей. Если используются хп, то их изменение в большинстве случаев не требует изменения клиентского приложения.

Здравствуйте, tpg, Вы писали:

tpg>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, Аноним, Вы писали:

А>>>>Расскажите как Вы используете ХП?

А>>>с использованием ХП — с ними гораздо проще, да и правильней рулить правами

А>>Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
А>>Причем в 2 из них придется передавать 30 параметров.
А>>Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А>>А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

А>>Потом добавляется одно поле. Надо поменять процедуру, надо в форме сделать во всех местах присвоение параметров. В общем на мой взгляд это не проще ...

А>>>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

А>>И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

tpg>Вообще то речь в цитируемом посте шла об управлении безопасностью.

Упс.... про безопасность проглядел. Сорри

Если говорить про безопасноссть и она очень нужна, то согласен ХП помогут

tpg>А насчет необходимости добавления одного поля в процессе эксплуатации... так это надо гнать с работы таких архитекторов и аналитьиков, ИМХО.

Поверьте это бывает достаточно часто, какими бы умными и головастыми аналитики не были

Просто есть клиент, который платит деньги, отсюда и все проблеммы ...

Здравствуйте, Аноним, Вы писали:

tpg>>А насчет необходимости добавления одного поля в процессе эксплуатации... так это надо гнать с работы таких архитекторов и аналитьиков, ИМХО.

А>Поверьте это бывает достаточно часто, какими бы умными и головастыми аналитики не были

А>Просто есть клиент, который платит деньги, отсюда и все проблеммы ...

Я ещё вел речь об архитекторах.
Абсолютно согласен с pkarklin насчет нормализации и распределения бизнес-логики (да и при применении N-слойной архитектуры с применением ХП ещё никто не помер

)...

Здравствуйте, pkarklin, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

А>>Проще? К примеру справочник организаций. В таблице порядка 30 полей. Мне чтобы сделать минимальный функционал надо написать как минимум 3 ХП(добавление и правка, удаление, список всех организаций).
А>>Причем в 2 из них придется передавать 30 параметров.
А>>Форма коррекции как выглядит? 30 контролов в которые надо данные из ХП загрузить, потом при сохранении понять были модификации или нет, потом из этих контролов данные назад в ХП передать.

А>>А так. TADOQuery. 30 DB контролов. и вызов метода CheckBrowseMode.

А>>Потом добавляется одно поле. Надо поменять процедуру, надо в форме сделать во всех местах присвоение параметров. В общем на мой взгляд это не проще ...

А>>>а небольшие запросы можно компоновать в одну ХП для удобства и вызывать с разными параметрами

А>>И во что потом превратиться эта ХП? Как быть с разработчиком, которму придется поддерживать потом эту систему?

P>Ну, канечно, проще с TADOQuery.

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

P>Другой аспект. Предположим, что Вы работаете непосредственно с таблицами (представлениями) с клиента, т.е. с явно зашитыми в клиента инструкциями по модификации данных. А теперь представьте себе, что возникла необходимость в изменении структуры хранения или алгоритма обработки. И мы лезем в проект, правим там, компилируем и ... теперь нам надо все это обновить у пользователей. Если используются хп, то их изменение в большинстве случаев не требует изменения клиентского приложения.

С этим соглашусь

Здравствуйте, tpg, Вы писали:

tpg>Здравствуйте, Аноним, Вы писали:

tpg>>>А насчет необходимости добавления одного поля в процессе эксплуатации... так это надо гнать с работы таких архитекторов и аналитьиков, ИМХО.

А>>Поверьте это бывает достаточно часто, какими бы умными и головастыми аналитики не были

А>>Просто есть клиент, который платит деньги, отсюда и все проблеммы ...

tpg>Я ещё вел речь об архитекторах.
tpg>Абсолютно согласен с pkarklin насчет нормализации и распределения бизнес-логики (да и при применении N-слойной архитектуры с применением ХП ещё никто не помер

)...

Что никто не помер это понятно

вопрос в количестве заморочек, которые эта архитектура порождает ...

Здравствуйте, Аноним, Вы писали:

А>Нормализация должна быть разумной

Я видел много программ и в них карточка клиента это много полей в одной таблице ... поверьте так проце всего.

Если мы говорим об OLTP системах, то номализация должна быть как раз "по самое не хочу". Только так можно добиться максимального быстродействия в транзакционной системе. Я тоже видел много программ, в которых были таблицы не по одному десятку полей, в которых 80% полей содержали NULL, что никак не добавляло быстродействию системы.

Здравствуйте, pkarklin, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

А>>Нормализация должна быть разумной

Я видел много программ и в них карточка клиента это много полей в одной таблице ... поверьте так проце всего.

P>Если мы говорим об OLTP системах, то номализация должна быть как раз "по самое не хочу". Только так можно добиться максимального быстродействия в транзакционной системе. Я тоже видел много программ, в которых были таблицы не по одному десятку полей, в которых 80% полей содержали NULL, что никак не добавляло быстродействию системы.

не люблю NULL

Здравствуйте, pkarklin, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

А>>Нормализация должна быть разумной

А>Люди. Я скорей с опросом, чем с вопросом.
А>Расскажите как Вы используете ХП?
А>Конкретно меня инетересует:
А>Вы делаете все через ХП, или все без ХП, или как-то разумно комбинируете?

Я не предпочитаю в основном,
т.к. часто стоит потребность работать с разными базами данных.

кроме того раньше они применялсиь для прекомпиляции — на слабых процах,
а теперь это не так актуально,

кроме того в АДО можно даже отдать команду — "прекомпилировать".

Когда же запросы сложные и извращенные по оптимизации,
на страницы кода,
тогда их удобно все-таки вынести в отдельный модуль — ХП.

Отлаживать, тестировать удобнее,
оправданная организация,
изредка скорость прекомпиляции важна.

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

Безопастностью же можно рулить кучей и других способов,
как в СOM+ — ведь это образец? — декларативная и интегрируемая безопастности.

Здравствуйте, vgrigor, Вы писали:

А>>Люди. Я скорей с опросом, чем с вопросом.
А>>Расскажите как Вы используете ХП?
А>>Конкретно меня инетересует:
А>>Вы делаете все через ХП, или все без ХП, или как-то разумно комбинируете?

V>Я не предпочитаю в основном,
V>т.к. часто стоит потребность работать с разными базами данных.

V>кроме того раньше они применялсиь для прекомпиляции — на слабых процах,
V>а теперь это не так актуально,

V>кроме того в АДО можно даже отдать команду — "прекомпилировать".

V>Когда же запросы сложные и извращенные по оптимизации,
V>на страницы кода,
V>тогда их удобно все-таки вынести в отдельный модуль — ХП.

V>Отлаживать, тестировать удобнее,
V>оправданная организация,
V>изредка скорость прекомпиляции важна.

V>А иначе заводить бодягу из-за мелких запросов- может и не умирал кто из за этого,
V>но просто не стоит оно того,
V>когда серьезной подсчитанной необходимости нет.

V>Безопастностью же можно рулить кучей и других способов,
V>как в СOM+ — ведь это образец? — декларативная и интегрируемая безопастности.

Согласен со увсем

Могу добавить что MSSQL(про других не знаю), планы исполнения не только процедур, но и обычных запросов хранит вместе с планами процедур.
И получается что при грамотном написании запросов(используя параметры), можно повысить скорость выполения запросов.

Здравствуйте, Аноним, Вы писали:

А>А еще клево, когда нет FK в базе

Ничего смешного. Многие высокопроизводительные системы именно так и работают.

Здравствуйте, Аноним, Вы писали:

А>не люблю NULL

Ты вобще кто и к чему это сказал?

Курить основы.

Здравствуйте, Аноним, Вы писали:

А>не люблю NULL

Ты просто не умеешь их готовить!

Здравствуйте, wildwind, Вы писали:

W>Ничего смешного. Многие высокопроизводительные системы именно так и работают.

+1
потому что большое количество "check'ов" foreign ключей снижает производительность

Здравствуйте, kallisto, Вы писали:

K>Здравствуйте, wildwind, Вы писали:

W>>Ничего смешного. Многие высокопроизводительные системы именно так и работают.

K>+1
K>потому что большое количество "check'ов" foreign ключей снижает производительность

-1
Ага. А реализация функционала "check'ов" и foreign ключей в коде типа повышает? Или Вы строите базы вообще без какой-либо Data Integrity?

Здравствуйте, pkarklin, Вы писали:

P>-1
P>Ага. А реализация функционала "check'ов" и foreign ключей в коде типа повышает? Или Вы строите базы вообще без какой-либо Data Integrity?

Это сильно грубо сказано или Вы меня не поняли.
Речь идёт вот о чём: допустим, что вы разрабатываете систему. И в данный момент занимаетесь проектированием и разработкой той части, которая будет "работать на СУБД". Вы приводите свою схему к определённому уровню нормализации пишете sp и триггеры. (Хочу заметить сразу, что частично реализовать функционал "check'ов" и foreign ключей на каком-либо из уровней всё равно придёться, потому что каскадное удаление, например, вы обеспечите с помощью триггеров, но вот при вставке вам всё равно придёться "ручками" искать родителя).

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

Что делать? Оптимизировали код — получили 5 секунд. Много. Отказались от триггеров, переписали часть кода — получили 4 секунды. Что делать? Ещё там что-то переделали — получили 3,5 секунды. Много — надо меньше! И тут умные люди предлакают отказаться от констреинтов по foreign key. Возникает вопрос: что мы теряем при отказе? И тут же получаем ответ — а ничего. От тригегеров, которые нам обеспечивали каскадное удаление и обновление мы уже отказались и эту логику реализовали по другому. При вставке мы и так родителя проверяем (не на уровне констреинтов). Тогда зачем нам дополнительные нагрузки? Удалили констреинты и получили 2,5 секунды. То что надо.

Здравствуйте, kallisto, Вы писали:

K>Вот вы разрабатываете, разрабатываете и доходите до той стадии, когда необходимо тестировать производительность системы на реальном кол-ве данных. И тут вдруг оказывается, что она работает "медленно".

Да, вот сам сейчас наблюдаю такой "классический" сценарий у соседней команды. Гораздо реже, к сожалению, это планируется еще при проектировании.

Здравствуйте, kallisto, Вы писали:

K>Здравствуйте, pkarklin, Вы писали:

P>>-1
P>>Ага. А реализация функционала "check'ов" и foreign ключей в коде типа повышает? Или Вы строите базы вообще без какой-либо Data Integrity?

K>Что делать? Оптимизировали код — получили 5 секунд. Много. Отказались от триггеров, переписали часть кода — получили 4 секунды. Что делать? Ещё там что-то переделали — получили 3,5 секунды. Много — надо меньше! И тут умные люди предлакают отказаться от констреинтов по foreign key. Возникает вопрос: что мы теряем при отказе? И тут же получаем ответ — а ничего. От тригегеров, которые нам обеспечивали каскадное удаление и обновление мы уже отказались и эту логику реализовали по другому. При вставке мы и так родителя проверяем (не на уровне констреинтов). Тогда зачем нам дополнительные нагрузки? Удалили констреинты и получили 2,5 секунды. То что надо.

Интереснаа логика, однако...

1. Зачем мне проверять "родителя", если это за меня гараздо эффективнее зделает FK?
2. Зачем мне в триггере проверять валидность значения поля, если это за меня гараздо эффективнее сделает CHECK.
3. И т.п.

Если Вы идете речь о том, что Вам надо не просто проверить валидности значения поля, но еще и в случаи нарушения валидности выдать "на гора" "человеческое сообщение об ошибке" и вы это реализовали в коде, то да, CHECK, как объект можно вроде бы не вешать! Тоже самое касается и других ограничений. Но тут остается лазейка для dbo. Причем, так сказать, он по своей невнимательности может обойти закодированные ограничения и нарваться на рассогласованность данных. И никаких напоминаний типа "Запрещается лезьт в базу руками" не хватит.

И что для Вас будет важно? Быстродействие — или быстродействие + консистентность данных. Я бы 10 раз подумал... Для повышения быстродействия можно найти другоие способы, кроме как снос DRI и иже с ними.

Здравствуйте, kallisto, Вы писали:

K>Здравствуйте, pkarklin, Вы писали:

P>>-1
P>>Ага. А реализация функционала "check'ов" и foreign ключей в коде типа повышает? Или Вы строите базы вообще без какой-либо Data Integrity?

K>Это сильно грубо сказано или Вы меня не поняли.
K>Речь идёт вот о чём: допустим, что вы разрабатываете систему. И в данный момент занимаетесь проектированием и разработкой той части, которая будет "работать на СУБД". Вы приводите свою схему к определённому уровню нормализации пишете sp и триггеры. (Хочу заметить сразу, что частично реализовать функционал "check'ов" и foreign ключей на каком-либо из уровней всё равно придёться, потому что каскадное удаление, например, вы обеспечите с помощью триггеров, но вот при вставке вам всё равно придёться "ручками" искать родителя).

K>Вот вы разрабатываете, разрабатываете и доходите до той стадии, когда необходимо тестировать производительность системы на реальном кол-ве данных. И тут вдруг оказывается, что она работает "медленно". Т.е. по требованиям он должна операцию N отрабатывать за 3 секунды, а отрабатывает её за 6 секунд.

K>Что делать? Оптимизировали код — получили 5 секунд. Много. Отказались от триггеров, переписали часть кода — получили 4 секунды. Что делать? Ещё там что-то переделали — получили 3,5 секунды. Много — надо меньше! И тут умные люди предлакают отказаться от констреинтов по foreign key. Возникает вопрос: что мы теряем при отказе? И тут же получаем ответ — а ничего. От тригегеров, которые нам обеспечивали каскадное удаление и обновление мы уже отказались и эту логику реализовали по другому. При вставке мы и так родителя проверяем (не на уровне констреинтов). Тогда зачем нам дополнительные нагрузки? Удалили констреинты и получили 2,5 секунды. То что надо.

Триггеры тормозят гораздо сильней чем декларативные ограничения на уровне FK. И сам микрософт советует их использовать пореже и поменьше.

Пока мне приходилось разрабатывать БД в которых надежность и валидность данных гораздо важней скорости. Хотя надо заметить, что на скорость работы жалоб не было. А вот ошибки в логике программы проскакивали и если бы не FK, то я болго парился бы с отладкой ...

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, kallisto, Вы писали:

K>>Вот вы разрабатываете, разрабатываете и доходите до той стадии, когда необходимо тестировать производительность системы на реальном кол-ве данных. И тут вдруг оказывается, что она работает "медленно".

W>Да, вот сам сейчас наблюдаю такой "классический" сценарий у соседней команды. Гораздо реже, к сожалению, это планируется еще при проектировании.

Посоветуйте им снести все FK в базе, может скорость увеличиться

нам только потом об этом расскажите

K>И тут умные люди предлакают отказаться от констреинтов по foreign key. Возникает вопрос: что мы теряем при отказе? И тут же получаем ответ — а ничего. От тригегеров, которые нам обеспечивали каскадное удаление и обновление мы уже отказались и эту логику реализовали по другому.

Во первых умные люди такого посоветовать не могут
А во вторых для каскадного удаления лучше использовать сами FK

каскадным обновлением за последние 5 лет ни разу не пользовался

Здравствуйте, pkarklin, Вы писали:

P>Для повышения быстродействия можно найти другоие способы, кроме как снос DRI и иже с ними.

Скажите у вас сотовый телефон есть или просто телефон?
Не было ли у вас такого, что компания-провайдер мобильных услуг немного вас общитывала?
А теперь представьте ситуацию, что таких как вы у нее 100.000 каждый месяц, а обращаются (замечают) — это единицы.
Вы спросите — почему они (провайдеры) такие негодяи? Отвечу так — они редко задумываются о поиске другого способа.

Понимайте, как знаете.

Здравствуйте, Аноним, Вы писали:

А>Пока мне приходилось разрабатывать БД в которых надежность и валидность данных гораздо важней скорости. Хотя надо заметить, что на скорость работы жалоб не было.
Тогда твоя позиция понятна. Желаю тебе получить разный опыт, поработать с большими объемами данных и near-real-time приложениями.

А>А вот ошибки в логике программы проскакивали и если бы не FK, то я болго парился бы с отладкой ...
Ну использовать FK при разработке и тестировании никто же не запрещает. Речь идет о production.

Они примерно как assert'ы в клиентском коде. В debug есть, в release нет. Но если не тормозят, то можно и оставить на всякий случай.

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, Аноним, Вы писали:

А>>Пока мне приходилось разрабатывать БД в которых надежность и валидность данных гораздо важней скорости. Хотя надо заметить, что на скорость работы жалоб не было.
W>Тогда твоя позиция понятна. Желаю тебе получить разный опыт, поработать с большими объемами данных и near-real-time приложениями.

А>>А вот ошибки в логике программы проскакивали и если бы не FK, то я болго парился бы с отладкой ...
W>Ну использовать FK при разработке и тестировании никто же не запрещает. Речь идет о production.

W>Они примерно как assert'ы в клиентском коде. В debug есть, в release нет. Но если не тормозят, то можно и оставить на всякий случай.

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

Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, Аноним, Вы писали:

А>>не люблю NULL

___>Ты вобще кто и к чему это сказал?

Вообще я это сказал косательно предыдущего сообщения

Здравствуйте, Аноним, Вы писали:

А>Кстати тут тоже одно но ... они(FK) замедляют работу только при обновлениях данных,
А>при выборках с джойнами они ускоряют(по крайне мере в MS SQL) он при постройке планов выполения их учитывает ...
Ускоряют не сами FK, а индексы, которые обычно используются вместе с ними. Тормозят, кстати, они же в основном.

А>так что надо смотреть каких операций больше идет ...
Верно.

Здравствуйте, pkarklin, Вы писали:

P>Интереснаа логика, однако...

Это не логика, это практика. Не частая, но имеющая место быть.

P>1. Зачем мне проверять "родителя", если это за меня гараздо эффективнее зделает FK?

И что, вы предлагаете каждый раз ловить ексепшен работы констреинта, если при вставке не было найдено родителя, нежели один раз написать, например, запрос со связанной переменной и просто биндить новое значение id_родителя (прошу не забывать, что речь идёт не о 10-ке таблиц с сотней строк каждая, и не о единичной вставке)

P>2. Зачем мне в триггере проверять валидность значения поля, если это за меня гараздо эффективнее сделает CHECK.
Никто не говорил про проверку значений в триггере

P>3. И т.п.

P>Если Вы идете речь о том, что Вам надо не просто проверить валидности значения поля, но еще и в случаи нарушения валидности выдать "на гора" "человеческое сообщение об ошибке" и вы это реализовали в коде, то да, CHECK, как объект можно вроде бы не вешать! Тоже самое касается и других ограничений. Но тут остается лазейка для dbo.
Какая?
P>Причем, так сказать, он по своей невнимательности может
Кто?
P>обойти закодированные ограничения и нарваться на рассогласованность данных. И никаких напоминаний типа "Запрещается лезьт в базу руками" не хватит.

Прошу не забывать, что речь идёт не о системе бухучёта. Вставка "руками" не выполняется вообще. Имеется одна подсистема, которая процессит данные в базе и есть другая подсистема, которая эти данные в базу скаладывает собирая их перед этим с CDR. Всё происходит без участия человека. О каких лазейках идёт речь?

P>И что для Вас будет важно? Быстродействие — или быстродействие + консистентность данных. Я бы 10 раз подумал... Для повышения быстродействия можно найти другоие способы
Это демагогия. Способы в студию — нам чужой опыт только в плюс пойдёт!

P>кроме как снос DRI и иже с ними.

Здравствуйте, kallisto, Вы писали:

K>потому что большое количество "check'ов" foreign ключей снижает производительность
Ребята, если вам удалось довести базу до того, что самое узкое место в ней это check констрейнты — снимаю шляпу.
В другом месте тюнить не пробовали?

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

... << RSDN@Home 1.1.4 beta 6a rev. 0>>

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, _d_m_, Вы писали:

___>>Здравствуйте, Аноним, Вы писали:

А>>>не люблю NULL

___>>Ты вобще кто и к чему это сказал?

А>Вообще я это сказал косательно предыдущего сообщения

Да вас анонимов не разобрать. Так что курить основы

Здравствуйте, kallisto, Вы писали:

K>Здравствуйте, pkarklin, Вы писали:

P>>-1
P>>Ага. А реализация функционала "check'ов" и foreign ключей в коде типа повышает? Или Вы строите базы вообще без какой-либо Data Integrity?

K>Вот вы разрабатываете, разрабатываете и доходите до той стадии, когда необходимо тестировать производительность системы на реальном кол-ве данных. И тут вдруг оказывается, что она работает "медленно". Т.е. по требованиям он должна операцию N отрабатывать за 3 секунды, а отрабатывает её за 6 секунд.

K>Что делать? Оптимизировали код — получили 5 секунд. Много. Отказались от триггеров, переписали часть кода — получили 4 секунды. Что делать? Ещё там что-то переделали — получили 3,5 секунды. Много — надо меньше! И тут умные люди предлакают отказаться от констреинтов по foreign key. Возникает вопрос: что мы теряем при отказе? И тут же получаем ответ — а ничего. От тригегеров, которые нам обеспечивали каскадное удаление и обновление мы уже отказались и эту логику реализовали по другому. При вставке мы и так родителя проверяем (не на уровне констреинтов). Тогда зачем нам дополнительные нагрузки? Удалили констреинты и получили 2,5 секунды. То что надо.

Ну тогда вам на Cache

переходить.

Поднимать производительность за счет FK — ни есть гуд. Необходимо создавать масштабируемые решения — и если надо получить 3 сек вместо 6 — надо с железяками решать. Оптимизировать можно по разному: секционировать, файлгруппы распределять по разным дискам, BBWC и пр.

Здравствуйте, 0rc, Вы писали:

0rc>Здравствуйте, pkarklin, Вы писали:

P>>Для повышения быстродействия можно найти другоие способы, кроме как снос DRI и иже с ними.

0rc>Скажите у вас сотовый телефон есть или просто телефон?

Дома просто, с собой сотовый.

0rc>Не было ли у вас такого, что компания-провайдер мобильных услуг немного вас общитывала?
За 2,5 года пользования услугами МТС — ниразу. МОжет повезло просто.

0rc>А теперь представьте ситуацию, что таких как вы у нее 100.000 каждый месяц, а обращаются (замечают) — это единицы.

Могу представить...
0rc>Вы спросите — почему они (провайдеры) такие негодяи? Отвечу так — они редко задумываются о поиске другого способа.

0rc>Понимайте, как знаете.

Вы знаете, мне трудно понять что Вы имели ввиду. Можно на пальцах объяснить Вашу мысль... Или, как сказано в х\ф Москва слезам не верит: "Переведи..."

Здравствуйте, 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, ведь это всего лишь один из подходов, дополнительный сервис, предоставляемый СУБД. Выбор тут также неоднозначен, как и с нормализацией-денормализацией. И в умных книжках вроде пишут, что целостность данных может обеспечиваться как на системном, так и на прикладном уровне.

Здравствуйте, wildwind, Вы писали:

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...
Вобщем, если вы разрабатывали (или видели как разрабатывают) системы масштаба национального оператора вы меня поймете

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 0rc, Вы писали:

0rc>Хм., дело вот в чем, что с теми провайдерами сотовой связи в которых (с которыми) мне приходилось иметь дело никогда(!) не использовали FK в таблицах общета абонентов, по причине нецелесообразности. Зачем? Вы все-равно не заметите, что вместо 56секунд разговора, модули ядра билиннга системы вас посчитали 2 раза по 56секунд, просто потому, что сотрудник компании запустил неумышленно модуль общета абон. базы. И это только один пример, а сколько еще багов дают нам NE, roaming, prepaid...
0rc>Вобщем, если вы разрабатывали (или видели как разрабатывают) системы масштаба национального оператора вы меня поймете

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

Ну, а то, что существующие биллинговые системы далеки от этого, то это можно отнести только на совесть их разработчиков. IMHO.

Здравствуйте, pkarklin, Вы писали:

P>В MS SQL Server мы как раз это можем:

P>ALTER TABLE ... CHECK | NOCHECK  CONSTRAINT  { ALL | constraint_name [ ,...n ] }

Можем-то можем, и не только в MS SQL Server, но на практике надеюсь применять не станем (в данном контексте).

Да, еще в некоторых случаях могут помочь deferred constraints.

Здравствуйте, pkarklin, Вы писали:

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 0rc, Вы писали:

0rc>Здравствуйте, pkarklin, Вы писали:

0rc>Существующие биллинговые системы далеки от этого, то это можно отнести только на опыт их разработчиков. IMHO.

Ну, что ж, каждый из нас, на сколько я понимаю, все равно останется при своем IMHO.

Здравствуйте, Merle, Вы писали:

M>Ребята, если вам удалось довести базу до того, что самое узкое место в ней это check констрейнты — снимаю шляпу.
M>В другом месте тюнить не пробовали?

M>Плюс не забывайте, что, как правило, грамотно спректированая база работает с FK и прочими констрейнтами шустрее чем без них, в силу того, что подобные вещи в некоторых случаях являются довольно существенными подсказками оптимизатору.

Про правильно спроектированную базу никто не говорил

так сказать "дарёному коню в зубы заглядать не дают". Шо имеем, на том и работаем.

Система уже давно в продакшене, да и абонентская база более 14 млн, вот только текущая схема не для такого количества данных. А на "том конце" ещё не созрели на её переработку. Заказчик решил, что купить новое железо+solaris будет дешевле, чем перелопатить всю структуру с импортом имеющихся данных.

Вот и дали немного исходники подправить и одним пальцем базу поковырять.

	От:	Аноним
	Дата:	27.09.05 14:53
	Оценка:

	От:	Пацак
	Дата:	27.09.05 15:01
	Оценка:	+1

	От:	ora
	Дата:	27.09.05 16:19
	Оценка:

От:	tpg	http://www.sql.ru/
Дата:	28.09.05 03:46
Оценка:

	От:	Аноним
	Дата:	28.09.05 05:46
	Оценка:

	От:	pkarklin
	Дата:	28.09.05 07:21
	Оценка:	3 (1) +1

От:	Merle	http://rsdn.ru
Дата:	29.09.05 21:25
Оценка:	1 (1) +2

	От:	_d_m_
	Дата:	30.09.05 01:48
	Оценка:

	От:	_d_m_
	Дата:	30.09.05 02:01
	Оценка: