Здравствуйте!
Есть таблица справочник "Типы товара" (TYPE) поля ID и NAME
и таблица "Список товаров" где поля ID, NAME, TYPE_ID (внешний ключ для типов товара). Нужно реализовать, чтобы нельзя было удалить запись из справочника "Типы товара", если этот тип уже использован в таблице "Список товаров". Реализовать на уровне БД. Если можно поподробнее для новичка.
Заранее спасибо.
Rocket
Запрет удаления через внешний ключ
какие мороки, откуда?Ага. Потом опять пойдет морока про "неселективный" индекс
на данном этапе человеку об этом думать не надо. Вот когда у него будет база с тучей таблиц, и будут таблицы с миллионом записей, которые ссылаются на справочник из 10 записей - тогда да, может быть, имеет смысл подумать про селективность.
И то, ответ на это есть тут:
IBAnalyst, Help, Дополнительные вопросы и ответы, пункты 7 и 8.
Видите ли, Дим. Где та четкая граница (я имею ввиду на каком миллионе записей), когда селективность индекса гарантированно начинает сказываться на производительности. Боюсь, что и тут Вы не дадите конкретного ответа (оно, канешна, правильно: лучше промолчать, чем ляпнуть). А работать с базой без привлечения администратора (который вовремя что-нить там подкрутит/подправит) уже становится трудным.kdv писал(а):Вот когда у него будет база с тучей таблиц, и будут таблицы с миллионом записей, которые ссылаются на справочник из 10 записей - тогда да, может быть, имеет смысл подумать про селективность.
Я вот тут пробежался глазом по диагонали статью про распростаненность применения разных серверов в медицине. Увы, на первом месте мелкомягкий сервер. А вот почему не FB? Вопрос, скорее, риторический
Вдогонку. Нам тут софт (отправка/получение результатов лабанализов по сети) поставляют (пока бесплатно) некие ребята из Москвы. Написан в MS Visual Studio(если память не изменяет). Так они там вообще mdb используют. Посмотрел. Улыбнуло. Но спорить не стал. Я всего лишь врач.
никаких граблей нет. и не надо преувеличивать про плохую селективность.Т.е., сначала надо наступить на грабли, а потом (изрядно поковырявшись в архивах обих форумов) править базу?
вопрос ... мягко скажем, детский.Я вот тут пробежался глазом по диагонали статью про распростаненность применения разных серверов в медицине. Увы, на первом месте мелкомягкий сервер. А вот почему не FB? Вопрос, скорее, риторический
то есть, "я не читал тот текст в справке IBAnalyst, но буду продолжать..."?Где та четкая граница (я имею ввиду на каком миллионе записей), когда селективность индекса гарантированно начинает сказываться на производительности.
значит, база данных так разработана. только не надо свои проблемы транслировать в проблемы вообще.А работать с базой без привлечения администратора (который вовремя что-нить там подкрутит/подправит) уже становится трудным.
Вспомнил. Обсуждали ужеkdv писал(а):то есть, "я не читал тот текст в справке IBAnalyst, но буду продолжать..."?Где та четкая граница (я имею ввиду на каком миллионе записей), когда селективность индекса гарантированно начинает сказываться на производительности.
Значит тогда тоже благоразумно ушли от конкретного ответа. Ладно. Извините, Дмитрий, за назойливость. Повторюсь как и в тот раз, пошел за своими граблями.
кто ушел, куда ушел, от чего ушел?Значит тогда тоже благоразумно ушли от конкретного ответа.
Ладно. Извините, Дмитрий, за назойливость.
Вот Вы, например, транслируете мысль - ЛЮБОЙ плохоселективный индекс - зло. Ну так будьте поконкретнее. Вы же предлагаете ересь - вместо FK строить целостность на триггерах.
Я Вас послал в КОНКРЕТНЫЙ ПРИМЕР, что именно можно контролировать на триггерах чтобы избавиться от такого "плохого" FK.
Вы даже не изволите смотреть?
Не надо делать общеполагающих выводов на основе Вашей базы данных. Что плохо у Вас, не обязательно плохо у других, и наоборот.
Это не я транслирую. Это следует из материалов форума на скулру, различной доки, в том числе и на Вашем сайте. Я лишь исхожу из предположения, что это потенциальный источник проблем, а значит рано или поздно они появятся. И их придется решать. Причем на рабочей базе.kdv писал(а):Вот Вы, например, транслируете мысль - ЛЮБОЙ плохоселективный индекс - зло.
Это не я, это Борриkdv писал(а):Вы же предлагаете ересь - вместо FK строить целостность на триггерах.
Причем, я имел ввиду именно таблицы соответствия (или LOOKUP-таблицы), а не любые ПК-ФК вообще.И потом, Вы же сами обозначены в книге научным редактором. Ко многим ее неоднозначным тезисам имеются Ваши комментарии. А вот по поводу "эмуляции" целостности на триггерах в таблицах соответствия - не припомню. Значит, согласны?
P.S. Уппс... Каюсь, узрел-узрел )) стр.683
"Уж послала, так послала!" (с)kdv писал(а):Я Вас послал в КОНКРЕТНЫЙ ПРИМЕР, что именно можно контролировать на триггерах чтобы избавиться от такого "плохого" FK.
Вы даже не изволите смотреть?
Дмитрий, не обижайтесь. Чесслово, я старательно полгода штудировал доку с Вашего сайта (уж простите за нарушение копирайта, собрал в один PDF и распечатал мелким шрифтом на 150 страниц), Борри (щас перечитываю осмысленными кусками в третий раз), архивы обоих форумов, прежде чем задать первый вопрос.
Опять же повторюсь. Нет у меня заполненной базы, из коей можно извлекать статистику и делать выводы. Есть готовый к употреблению клиент на mdb, который я перевожу на FB. Ну не нравится мне такой подход: скроить_штаны-померять-снять_и_перекроить-снова померять_снова_снять ... и т.д. Потому и замучил вопросами. Не взыщите.kdv писал(а):Не надо делать общеполагающих выводов на основе Вашей базы данных. Что плохо у Вас, не обязательно плохо у других, и наоборот.
Вы заморачиваетесь не теми проблемами. Разложите-ка по пунктам, чем настолько плохи плохоселективные индексы (простите за тафтологию), что их ни в коем случае нельзя использовать?eddoc писал(а):Это не я транслирую. Это следует из материалов форума на скулру, различной доки, в том числе и на Вашем сайте. Я лишь исхожу из предположения, что это потенциальный источник проблем, а значит рано или поздно они появятся. И их придется решать. Причем на рабочей базе.kdv писал(а):Вот Вы, например, транслируете мысль - ЛЮБОЙ плохоселективный индекс - зло.
Можно вслух?CyberMax писал(а):Разложите-ка по пунктам, чем настолько плохи плохоселективные индексы...
1. Медленная сборка мусора.
- у меня версия сервера 2.0.3, потому как вроде не грозит.
2. Больше операций чтения-записи при селекте/инсерте/удалении, если цепочка очень длинная
- таблицы детальки потенциально могут содержать до 100 000 ссылочных записей на 5-10 записей мастера. Вот тут я в затруднении, потому как даже прикинуть не могу, какая статистика чаще всего бывает в этом случае. Потому и с упорством идиота задаю этот вопрос kdv :)
а сейчас-то что - только желание подстелить соломки? Когда проблема появится, тогда ее и имеет смысл решать. Это, правда, относится только к данной проблеме, а не к любым.Я лишь исхожу из предположения, что это потенциальный источник проблем, а значит рано или поздно они появятся. И их придется решать. Причем на рабочей базе.
это значит, что я не ожидал что Хелен напишет подобную невнятную фигню. Соответственно, не вчитывался столь подробно.И потом, Вы же сами обозначены в книге научным редактором. Ко многим ее неоднозначным тезисам имеются Ваши комментарии. А вот по поводу "эмуляции" целостности на триггерах в таблицах соответствия - не припомню. Значит, согласны?
Вы собрали в кучу массу высказываний, и на их основании сделали свои собственные выводы. Которые слишком категоричны и прямолинейны.Дмитрий, не обижайтесь. Чесслово, я старательно полгода штудировал доку
о боже!Нет у меня заполненной базы, из коей можно извлекать статистику и делать выводы.
тогда к чему эти сентенции про "плохую селективность"? Или Вы не видите разницы между теорией и практикой? В статьях и книгах описывается что может быть, включая конкретные примеры. Но это не значит, что все изложенное там обязательно будет в Вашей базе данных на этапе разработки думать о замене ФК триггерами - это граничит с отклонениями, уж извините за прямоту. Тот пункт из хелпа ИБА, который я процитировал в другом топике, т.е. о возможном контроле целостности триггерами вместо ФК, он применяется только если с данным индексом совсем все плохо в конкретной ситуации!!!Ну не нравится мне такой подход: скроить_штаны-померять-снять_и_перекроить-снова померять_снова_снять ... и т.д.
Так что, стройте FK и не пудрите нам мозги
перестаньте нести ахинею, пожалуйста.Потому и с упорством идиота задаю этот вопрос kdv
все это вопросы ФУНКЦИОНИРОВАНИЯ РАБОЧЕЙ БД, а не проектирования.
Селективность индекса зависит от КОНКРЕТНЫХ ДАННЫХ столбца. И может быть предугадана лишь с определенной вероятностью на этапе проектирования. Но чтобы этим голову при проектировании забивать - весьма оригинальный подход.
Вы не думали например о том, что через год, когда у вас все будет в пром-эксплуатации работать, и компьютеры и диски будут гораздо быстрее, чем сейчас?