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


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

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

А>Здравствуйте, _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>Понимайте, как знаете.

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