Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
pingvin_winnie
Member

Откуда:
Сообщений: 5
gluks


Если работают только через приложение - смело удаляйте.


Это из серии "вредных советов" что ли? :-)

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

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

На уровне БД кроме ссылочной цело
26 июл 07, 15:56    [4440575]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
aaa2
Guest
pingvin_winnie
gluks


Если работают только через приложение - смело удаляйте.


Это из серии "вредных советов" что ли? :-)

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


Вы ничего не путаете про javascript? Может вы имели ввиду java?
26 июл 07, 15:58    [4440591]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
SvarogTFF
Member

Откуда: Киев
Сообщений: 163
Jannny
SvarogTFF
Beginner123456
Добрый день.
Смотрю вот на структуру одной системы...
Куча Foreign key в каждой таблице.
Причём, On Delete := No Action
В софте заполнение этих полей - строго через справочники (руками вводить запрещено) .
Вопрос: для чего вообще они нужны? Контроль правильности ввода возложен на софт.
Что будет, если вместо Форейн кей использовать обычный индекс?

По описанию похоже, что у вас поля, которые входят в состав Foreign key непроиндексированы.
Это из какой строчки описания ясно???

Неправильно заквотил-из этой
Beginner123456

PPS: Есть в базе мега-справочник и на него смотрит много форейн кеев. Программисты жалуются, что апдейты-удаления-инсёрты этого мега-справочника идут медленно из-за большого количества форейн кеев на него. Вот и возникла мысль: а нафиг они нужны?
26 июл 07, 16:00    [4440603]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
SvarogTFF
Beginner123456
Добрый день.
Смотрю вот на структуру одной системы...
Куча Foreign key в каждой таблице.
Причём, On Delete := No Action
В софте заполнение этих полей - строго через справочники (руками вводить запрещено) .
Вопрос: для чего вообще они нужны? Контроль правильности ввода возложен на софт.
Что будет, если вместо Форейн кей использовать обычный индекс?

Сорри за мультипост. Наличие Foreign key не означает автоматического наличия индекса. Это разные вещи. По описанию похоже, что у вас поля, которые входят в состав Foreign key непроиндексированы.


+1. Нужно проанализировать причину замедления.

Если дело действительно в проверке большого числа FK, то их запрещение не самое плохое решение. Доводы из разряда, как бы чего не вышло выглядят слабо. Формально, нужно сравнить риски связанные с нарушением целостности БД в результате ошибки пользователя с рисками связанными с медленной работой системы и прочими рисками. Если, (грубо говоря) риск нарушения целостности БД не превышает расходы на регламентные работы, то может быть и фиг с ним. Почаще резервируйте справочник, тогда случайное удаление записей из него не станет катострофой.
26 июл 07, 16:00    [4440604]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
gluks
Guest
SvarogTFF
gluks

Если работают только через приложение - смело удаляйте. Индексы только создайте по необходимости. Производительность увеличится от 10%.

Очень смело и... глупо.
1. Где гарантия, что не будет ошибки в коде приложения? Особенно это будет весело, когда ошибка выявится через полгода и получим не базу данных, а мусорную кучу.
2. Клиент легко поломать-и если проверки в нем, то это не защитит базу.
3. Как сказали выше, сделать быстрее, чем это делает Оракл не выйдет.
4. Уверены, что предусмотрели все? Например, я делаю проверку, одновременно, со мной еще кто-то делает проверку. Нарушений нет. Оба делаем комит и в базе получаем данные, которые не соответсвуют заданному ограничению целлостности?


1. А где гарантия что не будет ошибок в FK?
2. Логика приложения может находиться в хранимых процедурах в БД или в серверном приложении(типа сервлетов) и никто ничего не взломает.
3. Тот же Т. Кайт пишет в своих книгах что FK уменьшает производительнось на 10-15%
4. При работе с FK при опредленных условиях могут создаваться блокировки, которые буду жутко тормозить работу юзеров.

Подумайте также по массовую вставку. Если вы реализуете проверки в приложении, то для работы в режиме OLTP вы пишите проверку существования пары строк, а при массовом вводе достаточно проверить один раз, а потом вливать. В случае же с FK для OLTP нормально, а для массового ввода - хреново. Причем не отключишь никак. Физически вы сможете констрейнт выключить, но поскольку логика приложения у вас не предусматривает проверки, то OLTP-юзера за это время при выключенном FK вам точно нахреначат.
26 июл 07, 16:20    [4440802]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63954
Блог
mcureenab
Если дело действительно в проверке большого числа FK, то их запрещение не самое плохое решение. Доводы из разряда, как бы чего не вышло выглядят слабо.

Это слова человека, которому ни разу не приходилось спасать данные из систем, в которых "чего вышло".

mcureenab
Формально, нужно сравнить риски

Формально - да. Фактически результат сравнения давно и надежно известен.
26 июл 07, 16:28    [4440876]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
SvarogTFF
Member

Откуда: Киев
Сообщений: 163
gluks

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

Без блокировок нельзя реализовать проверку - подумай. Другое дело, что нужно при проверке уменьшить время существования блокировки и количество заблокированых строк. И кстати отсутствие индекса по FK (при редактировании полей , входящих в состав FK, в родительской таблице, и т.п.) и есть эти самые "определенные условия".
26 июл 07, 16:36    [4440946]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
gluks
Guest
SvarogTFF
gluks

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

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


Это все понятно.

Если подытожить- при желании криво можно реализовать и при FK и при отсутствии FK и проверках в приложении. Но если приложении изначально писалось с проверкой, то FK дает только лишние издержки.
26 июл 07, 16:44    [4441026]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
gluks
Это все понятно.

Если подытожить- при желании криво можно реализовать и при FK и при отсутствии FK и проверках в приложении. Но если приложении изначально писалось с проверкой, то FK дает только лишние издержки.

1) Т.е. вы готовы преодолеть ограничение, налагаемое включенным FK?
2) Покажите вашу проверку. 10/1 , что это типа-проверка
26 июл 07, 16:52    [4441121]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
gluks
Guest
Не совсем понял что вы имеете ввиду. Может конкретный пример приведете, а я реализацию попробую сделать(хотя бы схематично).
26 июл 07, 16:56    [4441165]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
Можно на последние деньги строить бомбоубежище на случай атомной войны и сдохнуть от голода молодым. А можно ни в чём себе не отказывать, и умереть в здравом уме и твёрдом теле в преклонном возрасте. Разумный подход к проблеме - ключ к успеху.

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

Это слова человека, которому ни разу не приходилось спасать данные из систем, в которых "чего вышло".

mcureenab
Формально, нужно сравнить риски

Формально - да. Фактически результат сравнения давно и надежно известен.


Простите, это ничем не подкреплённое заявление. Мелочи не доставляют хлопот пока им уделяешь должное внимание. Рисками можно и нужно управлять. Так регулярное резервирование справочника существенно снижает последствия от его потери. Например, в случае ошибочного update неключевой колонки справочника FK никак не поможет сохранить целостность данных. Да. Суррогатные ключи сохранятся, что что толку от них, если потеряно отображение суррогатного ключа на реальный? Если оценивать только эти риски, то они (ИМХО) будут примерно одного порядка, т.е. даже из этого пример видно, что FK решает лишь пол задачи.

ИМХО, проблема в том, что в ситеме заведён один мегасправочник, на который ссылается куча внешних ключей, так что изменение ключевого поля записи в любом тематическом разделе справочника приводит к проверке практически всей БД. Тут имеет смысл выполнить горизонтальную декомпозицию справочника, так чтобы в одной справочной таблице хранилось небольшое число словарных статей из близких по смыслу доменов. В пределе в одной таблице должен храниться один справочник, но сопровождать кучу таблиц может быть неудобно. Когда на отдельную справочную таблицу будут ссылаться значительно меньшее количество FK, соответственно сократиться и число проверок.

Можно выделить неизменяемые справочники, и удалить FK на них или выделить эти справочники в отдельную таблицу. Так же следует рассмотреть возможность удаления FK из больших таблиц, проверка которых занимает больше всего времени или опять же выделить эти справочники в отдельную таблицу/цы, чтобы изменение других справочников не цепляло большие таблицы.
26 июл 07, 17:40    [4441576]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
orawish
gluks
Это все понятно.

Если подытожить- при желании криво можно реализовать и при FK и при отсутствии FK и проверках в приложении. Но если приложении изначально писалось с проверкой, то FK дает только лишние издержки.

1) Т.е. вы готовы преодолеть ограничение, налагаемое включенным FK?
2) Покажите вашу проверку. 10/1 , что это типа-проверка


Когда пользователь выбирает словарную статью только из предложенного списка, то какой смысл проверять (хоть в приложении, хоть FK) что он ввёл посторонний код, ведь он может ввести только разрешённое значение. (Это если кратко).
26 июл 07, 18:01    [4441715]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
mcureenab
..Когда пользователь выбирает словарную статью только из предложенного списка, то какой смысл проверять (хоть в приложении, хоть FK) что он ввёл посторонний код, ведь он может ввести только разрешённое значение. (Это если кратко).

Ну а, допустим, некто хочет удалить строку из справочника..
26 июл 07, 18:07    [4441765]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63954
Блог
mcureenab
Простите, это ничем не подкреплённое заявление.

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

mcureenab
Мелочи не доставляют хлопот пока им уделяешь должное внимание.

Должное внимание стоит денег. Оптимальное по стоимости должное внимание - избавиться от возможности проблемы.

mcureenab
Так регулярное резервирование справочника существенно снижает последствия от его потери.

Потеря справочника - весьма незначительный риск, не имеющий отношения к реальным потерям от нарушения ссылочной целостности.

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

mcureenab
Если оценивать только эти риски, то они (ИМХО) будут примерно одного порядка,

Если оценивать только этот бит из числа "миллион", он будет примерно одного порядка с числом "ноль"

Да, внешние ключи "решают только ползадачи", скорее даже меньше. Они не избавляют от необходимости во многих других проверках. Однако, свою часть задачи они решают отменно, на уровне must have.

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

Так вот, поверьте: девять проблем из каждых десяти были из-за нарушения ссылочной целостности. После того как я во-первых глобально исправил текущие "висящие ссылки", а во-вторых, написал ночной job, который искал, находил и писал мне письмо - количество заявок от пользователей упало на порядок. А после того как я раскопал и выправил причины возникновения на основных таблицах - проблемы со ссылками стали возникать не чаще раза в месяц, после очередных художеств программистов.

mcureenab
ИМХО, проблема в том, что в ситеме заведён один мегасправочник,

C этим я вполне вероятно соглашусь. Конечно, для категоричного суждения нужно больше информации, но гипотеза весьма правдоподобна.

mcureenab
так что изменение ключевого поля записи в любом тематическом разделе справочника приводит к проверке практически всей БД.

Я все же надеюсь, что до изменения ключей они не дошли. Хотя, конечно, могли.

mcureenab
Так же следует рассмотреть возможность удаления FK

Не следует рассматривать эту возможность. Вернее, я на 99.9% уверен, что менять в системе надо совсем другое. И процентов на восемьдесят - что проблема может быть исправлена удалением какой-нибудь локальной глупости.
26 июл 07, 18:17    [4441838]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
orawish
mcureenab
..Когда пользователь выбирает словарную статью только из предложенного списка, то какой смысл проверять (хоть в приложении, хоть FK) что он ввёл посторонний код, ведь он может ввести только разрешённое значение. (Это если кратко).

Ну а, допустим, некто хочет удалить строку из справочника..


Это конечно проблема... которая исходит из того, что пользователи системы не подчиняются никаким правилам. Формально, такая система не сможет работать ни с FK ни без них. Реальные информационные системы требуют от персонала и пользователей соблюдения ряда правил и ограничивают доступ к некоторым операциям, пользователи отвечают за свои действия, в итоге мы получаем вполне работоспособную систему, ну а если она в добавок является бдительной и при этом не создаёт необоснованных проблем, то это дополнительный +.
26 июл 07, 18:23    [4441878]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63954
Блог
mcureenab
в итоге мы получаем вполне работоспособную систему,

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

По моей оценке, кстати, это одно из труднейших, может быть труднейшее занятие в ИТ. Что-нибудь типа "исправить созданные полгода назад данные так, как они должны были бы выглядеть, если бы вот эта дрянная закорючка работала как надо".
26 июл 07, 18:44    [4441981]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
softwarer

Так вот, поверьте: девять проблем из каждых десяти были из-за нарушения ссылочной целостности. После того как я во-первых глобально исправил текущие "висящие ссылки", а во-вторых, написал ночной job, который искал, находил и писал мне письмо - количество заявок от пользователей упало на порядок. А после того как я раскопал и выправил причины возникновения на основных таблицах - проблемы со ссылками стали возникать не чаще раза в месяц, после очередных художеств программистов.


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

Удаление FK на больших талицах может реально поднять производительность. Довод такой.
Проверка FK при вставке записи требует чтения индекса PK, что замедляет вставку.
Проверка FK при удалении родительской записи требует поиска дочерних записей.
Проблему поиска могут решить индексы на FK, но в больших таблицах они весьма накладны по объёму данных и сильно замедляют операции вставки записей.
В итоге имеем, что для высокопроизводительных программ простое решение не канает, поскольку требует затрат на более скоростное оборудование (если каковое вообще сущетсвует).

softwarer

mcureenab
так что изменение ключевого поля записи в любом тематическом разделе справочника приводит к проверке практически всей БД.

Я все же надеюсь, что до изменения ключей они не дошли. Хотя, конечно, могли.


А иначе что у них может тормозить?
26 июл 07, 18:48    [4442008]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
mcureenab
orawish
mcureenab
..Когда пользователь выбирает словарную статью только из предложенного списка, то какой смысл проверять (хоть в приложении, хоть FK) что он ввёл посторонний код, ведь он может ввести только разрешённое значение. (Это если кратко).

Ну а, допустим, некто хочет удалить строку из справочника..


Это конечно проблема... которая исходит из того, что пользователи системы не подчиняются никаким правилам. Формально, такая система не сможет работать ни с FK ни без них. Реальные информационные системы требуют от персонала и пользователей соблюдения ряда правил и ограничивают доступ к некоторым операциям, пользователи отвечают за свои действия, в итоге мы получаем вполне работоспособную систему, ну а если она в добавок является бдительной и при этом не создаёт необоснованных проблем, то это дополнительный +.

FK no action реализуют парадигму фиг удалишь то,что используется. Это, имхо, очень правильный сценарий. С одной стороны - позволяет работать без паранойи при редактировании справочников, с другой стороны - реальная защита фактических данных. Т.е. бдить - именно помогает, прозрачно увеличивая меру ответственности при работе с общими данными.
Хотя исключения, когда FK не надобен/не_реализуем, иногда таки бывают.
26 июл 07, 18:55    [4442036]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
stax..
Guest
слышал такую крамолу,
что в оракловской сюите (или как там счас называется) очень мало fk
если правда, то неспроста
.....
stax
26 июл 07, 18:57    [4442046]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
pingvin_winnie
Member

Откуда:
Сообщений: 5
aaa2
pingvin_winnie
gluks


Если работают только через приложение - смело удаляйте.


Это из серии "вредных советов" что ли? :-)

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


Вы ничего не путаете про javascript? Может вы имели ввиду java?


ничего не путаю :-) Вся проверка введенных (или невведенных) данных делается через javascript. При отключении javascript в броузере ломается все :-)
26 июл 07, 18:58    [4442053]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
stax..
слышал такую крамолу,
что в оракловской сюите (или как там счас называется) очень мало fk
если правда, то неспроста
.....
stax
Они описаны в доке (в том числе процентов на 85 правдиво ) и отсутствуют физически - в подавляющем большинстве случаев. Ну и любовь к кастомизации в гыбкых полях (чуть ни в каждой табличке) тоже никак на нормальное проектирование не похожа.

(козлы, козлы, козлы )
26 июл 07, 19:02    [4442068]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
softwarer
mcureenab
в итоге мы получаем вполне работоспособную систему,

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

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


Если Вы придумали плохое решение, то это не значит, что я тоже придумал плохое решение. Качество данных зависит от их использования. Если в системе нет никаких механизмов проверки целостности данных ни внутренних ни внешних, то естественно со временем мы получим "дерьмо из лопнувшей канализации". Чтобы дерьмо не накапливалось, в системе должна существовать корректирующая обратная связь.
26 июл 07, 19:02    [4442069]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
Двоюшник
Member

Откуда: Киев
Сообщений: 1135
stax..
слышал такую крамолу,
что в оракловской сюите (или как там счас называется) очень мало fk
если правда, то неспроста
.....
stax

оно и так там все тормозит...
SQL> select count(1) from all_objects;

  COUNT(1)
----------
    235061

SQL> 
26 июл 07, 19:04    [4442078]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
pingvin_winnie
Member

Откуда:
Сообщений: 5
gluks
2. Логика приложения может находиться в хранимых процедурах в БД или в серверном приложении(типа сервлетов) и никто ничего не взломает.


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

И самое главное - зачем изобретать велосипед? Как уже писали - если БД умеет что-то делать, то скорее всего, она умеет это делать лучше, чем вы :-).
26 июл 07, 19:10    [4442089]     Ответить | Цитировать Сообщить модератору
 Re: Провокационный вопрос: зачем нужны Foreign key?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63954
Блог
mcureenab
Я так понял, что проблема была решена без всяких там FK,

Решена проблема не была. Путем введения дополнительных неэффективных проверок ее тяжесть была значительно уменьшена; в частности, в большинстве случаев я успевал найти и заблокировать проблему раньше, нежели ее замечали пользователи.

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

mcureenab
т.е. приложив определённые усилия без FK вполне можно обойтись.

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

mcureenab
Удаление FK на больших талицах может реально поднять производительность. Довод такой.

На эту тему на предыдущей странице было приведено высказывание Кайта, очевидно истинное.

mcureenab
В итоге имеем, что для высокопроизводительных программ простое решение не канает,

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

Вспоминается цитата, которую года полтора назад публиковал Вадим Максимов - "в системе реализован менеджер блокировок гораздо более эффективный, чем в Oracle; он требует 300Мб серверной памяти и из-за него мы рекомендуем ребутить сервер каждую неделю".
26 июл 07, 19:12    [4442093]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить