iBase.ru Forum

Здравствуйте!
Есть таблица справочник "Типы товара" (TYPE) поля ID и NAME
и таблица "Список товаров" где поля ID, NAME, TYPE_ID (внешний ключ для типов товара). Нужно реализовать, чтобы нельзя было удалить запись из справочника "Типы товара", если этот тип уже использован в таблице "Список товаров". Реализовать на уровне БД. Если можно поподробнее для новичка.

Заранее спасибо.
Rocket

Вдумчиво читай собственный сабж и поступи соотвественно.

нужен foreign key? ну так создай его...

kdv писал(а):нужен foreign key? ну так создай его...

ОФФ.

Rocket писал(а):Есть таблица справочник ...

Ага. Потом опять пойдет морока про "неселективный" индекс

Не понял ни "офф", ни "ага".
Вы по-русски писать умеете? У кого морока с индексом?

Ага. Потом опять пойдет морока про "неселективный" индекс

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

И то, ответ на это есть тут:
IBAnalyst, Help, Дополнительные вопросы и ответы, пункты 7 и 8.

kdv писал(а):И то, ответ на это есть тут:
IBAnalyst, Help, Дополнительные вопросы и ответы, пункты 7 и 8.

Т.е., сначала надо наступить на грабли, а потом (изрядно поковырявшись в архивах обих форумов) править базу?

WildSery писал(а):Не понял ни "офф", ни "ага".
Вы по-русски писать умеете? У кого морока с индексом?

Фигурными скобками надо объединить ("ОФФ", "Rocket писал(а):" и "Ага")

kdv писал(а):Вот когда у него будет база с тучей таблиц, и будут таблицы с миллионом записей, которые ссылаются на справочник из 10 записей - тогда да, может быть, имеет смысл подумать про селективность.

Видите ли, Дим. Где та четкая граница (я имею ввиду на каком миллионе записей), когда селективность индекса гарантированно начинает сказываться на производительности. Боюсь, что и тут Вы не дадите конкретного ответа (оно, канешна, правильно: лучше промолчать, чем ляпнуть). А работать с базой без привлечения администратора (который вовремя что-нить там подкрутит/подправит) уже становится трудным.
Я вот тут пробежался глазом по диагонали статью про распростаненность применения разных серверов в медицине. Увы, на первом месте мелкомягкий сервер. А вот почему не FB? Вопрос, скорее, риторический

Вдогонку. Нам тут софт (отправка/получение результатов лабанализов по сети) поставляют (пока бесплатно) некие ребята из Москвы. Написан в MS Visual Studio(если память не изменяет). Так они там вообще mdb используют. Посмотрел. Улыбнуло. Но спорить не стал. Я всего лишь врач.

Т.е., сначала надо наступить на грабли, а потом (изрядно поковырявшись в архивах обих форумов) править базу?

никаких граблей нет. и не надо преувеличивать про плохую селективность.

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

вопрос ... мягко скажем, детский.

Где та четкая граница (я имею ввиду на каком миллионе записей), когда селективность индекса гарантированно начинает сказываться на производительности.

то есть, "я не читал тот текст в справке IBAnalyst, но буду продолжать..."?

А работать с базой без привлечения администратора (который вовремя что-нить там подкрутит/подправит) уже становится трудным.

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

eddoc писал(а):Я всего лишь врач.

Психотерапеут, тоиссь мозгоклюй? Гарантирую, что если в 10-миллионнике сделать индекс по полю да/нет и пару-тройку раз подряд удалить-вставить с полмиллиона - будет затяжной свип, текущая работа сильно не пострадает. Полегчало?

Merlin писал(а):

eddoc писал(а):Нам тут софт (отправка/получение результатов лабанализов по сети) поставляют

Психотерапеут, тоиссь мозгоклюй?

Нет, "пиписькин" врач Полегчало?

kdv писал(а):

Где та четкая граница (я имею ввиду на каком миллионе записей), когда селективность индекса гарантированно начинает сказываться на производительности.

то есть, "я не читал тот текст в справке IBAnalyst, но буду продолжать..."?

Вспомнил. Обсуждали уже Значит тогда тоже благоразумно ушли от конкретного ответа.

Ладно. Извините, Дмитрий, за назойливость. Повторюсь как и в тот раз, пошел за своими граблями.

Мыши плакали, давились, но продолжали жрать кактус (ц)

Значит тогда тоже благоразумно ушли от конкретного ответа.
Ладно. Извините, Дмитрий, за назойливость.

кто ушел, куда ушел, от чего ушел?

Вот Вы, например, транслируете мысль - ЛЮБОЙ плохоселективный индекс - зло. Ну так будьте поконкретнее. Вы же предлагаете ересь - вместо FK строить целостность на триггерах.
Я Вас послал в КОНКРЕТНЫЙ ПРИМЕР, что именно можно контролировать на триггерах чтобы избавиться от такого "плохого" FK.
Вы даже не изволите смотреть?

Не надо делать общеполагающих выводов на основе Вашей базы данных. Что плохо у Вас, не обязательно плохо у других, и наоборот.

kdv писал(а):Вот Вы, например, транслируете мысль - ЛЮБОЙ плохоселективный индекс - зло.

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

kdv писал(а):Вы же предлагаете ересь - вместо FK строить целостность на триггерах.

Это не я, это Борри Причем, я имел ввиду именно таблицы соответствия (или LOOKUP-таблицы), а не любые ПК-ФК вообще.

И потом, Вы же сами обозначены в книге научным редактором. Ко многим ее неоднозначным тезисам имеются Ваши комментарии. А вот по поводу "эмуляции" целостности на триггерах в таблицах соответствия - не припомню. Значит, согласны?

P.S. Уппс... Каюсь, узрел-узрел )) стр.683

kdv писал(а):Я Вас послал в КОНКРЕТНЫЙ ПРИМЕР, что именно можно контролировать на триггерах чтобы избавиться от такого "плохого" FK.
Вы даже не изволите смотреть?

"Уж послала, так послала!" (с)

Дмитрий, не обижайтесь. Чесслово, я старательно полгода штудировал доку с Вашего сайта (уж простите за нарушение копирайта, собрал в один PDF и распечатал мелким шрифтом на 150 страниц), Борри (щас перечитываю осмысленными кусками в третий раз), архивы обоих форумов, прежде чем задать первый вопрос.

kdv писал(а):Не надо делать общеполагающих выводов на основе Вашей базы данных. Что плохо у Вас, не обязательно плохо у других, и наоборот.

Опять же повторюсь. Нет у меня заполненной базы, из коей можно извлекать статистику и делать выводы. Есть готовый к употреблению клиент на mdb, который я перевожу на FB. Ну не нравится мне такой подход: скроить_штаны-померять-снять_и_перекроить-снова померять_снова_снять ... и т.д. Потому и замучил вопросами. Не взыщите.

eddoc писал(а):

kdv писал(а):Вот Вы, например, транслируете мысль - ЛЮБОЙ плохоселективный индекс - зло.

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

Вы заморачиваетесь не теми проблемами. Разложите-ка по пунктам, чем настолько плохи плохоселективные индексы (простите за тафтологию), что их ни в коем случае нельзя использовать?

CyberMax писал(а):Разложите-ка по пунктам, чем настолько плохи плохоселективные индексы...

Можно вслух?
1. Медленная сборка мусора.
- у меня версия сервера 2.0.3, потому как вроде не грозит.
2. Больше операций чтения-записи при селекте/инсерте/удалении, если цепочка очень длинная
- таблицы детальки потенциально могут содержать до 100 000 ссылочных записей на 5-10 записей мастера. Вот тут я в затруднении, потому как даже прикинуть не могу, какая статистика чаще всего бывает в этом случае. Потому и с упорством идиота задаю этот вопрос kdv :)

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

а сейчас-то что - только желание подстелить соломки? Когда проблема появится, тогда ее и имеет смысл решать. Это, правда, относится только к данной проблеме, а не к любым.

И потом, Вы же сами обозначены в книге научным редактором. Ко многим ее неоднозначным тезисам имеются Ваши комментарии. А вот по поводу "эмуляции" целостности на триггерах в таблицах соответствия - не припомню. Значит, согласны?

это значит, что я не ожидал что Хелен напишет подобную невнятную фигню. Соответственно, не вчитывался столь подробно.

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

Вы собрали в кучу массу высказываний, и на их основании сделали свои собственные выводы. Которые слишком категоричны и прямолинейны.

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

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

Ну не нравится мне такой подход: скроить_штаны-померять-снять_и_перекроить-снова померять_снова_снять ... и т.д.

на этапе разработки думать о замене ФК триггерами - это граничит с отклонениями, уж извините за прямоту. Тот пункт из хелпа ИБА, который я процитировал в другом топике, т.е. о возможном контроле целостности триггерами вместо ФК, он применяется только если с данным индексом совсем все плохо в конкретной ситуации!!!

Так что, стройте FK и не пудрите нам мозги

Потому и с упорством идиота задаю этот вопрос kdv

перестаньте нести ахинею, пожалуйста.
все это вопросы ФУНКЦИОНИРОВАНИЯ РАБОЧЕЙ БД, а не проектирования.

Селективность индекса зависит от КОНКРЕТНЫХ ДАННЫХ столбца. И может быть предугадана лишь с определенной вероятностью на этапе проектирования. Но чтобы этим голову при проектировании забивать - весьма оригинальный подход.
Вы не думали например о том, что через год, когда у вас все будет в пром-эксплуатации работать, и компьютеры и диски будут гораздо быстрее, чем сейчас?