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

Логика: ...что касается понятия "ключ", используемого в реляционной теории, то его использование в рамках этой теории без соответствующих определяющих признаков ("первичный", "потенциальный", "внешний" и т.д.) приводит ошибочным выводам на основе так называемой ошибки неясности и расплывчатости , заключающейся в том, что используемое в отдельности понятие "ключ" является неясным и расплывчатым без признаков, входящих в его определение...

2 kondi:
Здесь я с Вами согласен, тем более что в соседнем топике Вы нарушили это правило.

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

2 kondi:
Зачем-же так откровенно лгать?

Никакой лжи - вот ваши же посты:

Дата: 30 апр 03, 16:01
Имеем: изделия, сырье, полуфабрикаты и рецептуры продуктов и изделий

Как было сделано мной на Clipper-е
Таблица Prod – изделия (поля: ID_Prod, Name_Prod)
Таблица Raw – сырье и полуфабрикаты (ID_Raw, Name_Raw)
Таблица RcProd – рецептуры изделий (ID_Prod, Flag_RP_Comp, ID_RP_Comp, Weight)
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw, Flag_RP_Comp, ID_RP_Comp, Weight)

Т.е. рецептура изделия может содержать как сырье (и полуфабрикаты), так и изделия, например для рецептур наборов изделий (т.е. набор являясь изделием сам состоит из готовых изделий) Поле ID_RP_Comp в зависимости от значения поля Flag_RP_Comp ссылается на ID_Raw из Raw, или на ID_Prod из Prod. Аналогично рецептура полуфабриката может включать готовое изделие.

При такой структуре таблиц поддерживать ссылочную целостность приходится вручную.

Хочу при переходе на SQL Server предоставить эти заботы самой СУБД.

Выхода вижу два
1) слить все в 2 таблицы
Таблица RP – изделия, сырье и полуфабрикаты (ID_RP, Name_RP, Flag_RP)
Таблица RcRP – рецептуры (ID_RP, ID_RP_Comp, Weight)

Для удобства работы сделать представления для RP используя поле Flag_RP, чтобы готовые изделия, полуфабликаты и сырье оказались в разных представлениях.

2) изменить структуру таблиц с рецептурами
Таблица RcProd – рецептуры продуктов (ID_Prod, ID_Raw_Comp, ID_Prod_Comp, Weight)
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw, ID_Raw_Comp, ID_Prod_Comp, Weight)

Тогда ID_Raw_Comp будет ссылаться на ID_Raw из Raw, а ID_Prod_Comp на ID_Prod из Prod, конечно одно из этих полей должно быть равно NULL

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

Никаких намеков на то, что ID_RP, ID_Prod или ID_Raw - внешние ключи. Про то, что это ключи, кстати, тоже надо было догадаться по их "ID_"

Дата: 1 май 03, 17:19
>Далее: у вас в подходе 1) получается, что если RcRP.ID_RP - ключ, то рецептура может состоять
>только из 1-го изделия/сырья/полуфабриката, но по-вашему же это не так: рецептура изделия
>может содержать как сырье (и полуфабрикаты), так и изделия,...

Я что где-то писал что RcRP.ID_RP это ПЕРВИЧНЫЙ ключ? А что ключи бывают только УНИКАЛЬНЫМИ? Да-ааа, с такими знаниями реляционной теории, SQL точно не поможет, а в Clipper-е вообще утонуть можно

Репликант, за мной не заржавеет ;)

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

Eсли это Вам не видно сразу, включите поиск и увидите что Репликант сказал "ключ" без какого-бы то нибыло уточнения о каком ключе идет речь.

Все ясно: свои советы приберегите для себя - они вам гораздо нужнее!

За свои слова отвечать надо, а не хочется, да? Или Вы это другой Репликант?

Я за свои слова отвечаю и доказал это в очередной раз. Как насчет вас? И не надо передергивать насчет "другого" Репликанта

Согласен я с Вами, но в учебной литературе говорят "ключ" а потом объясняют какими они бывают, вот и все.

Что вместо словосочетания "потенциальный/первичный/внешний ключ" используется "ключ потенциальный потенциальный/первичный/внешний" и поэтому это вас смущает? Если же в самом тексте (а не в заголовке) вообще определяется термин "ключ" без чего-либо ("потенциальный" и т.д) или используется, а в контексте нет информации о том какой он ("потенциальный" и т.д), то это уже чистой воды отсебятина (интересно даже что это за Интернет-ресурс или книжка?) и учебной литературой это не является поскольку противоречит официальной реляционной теории, изложенной и основополагающей в многочисленных трудах-книжках Кодда,Бойса,Чамберлина,Чена,Навата,Дейта и т.д и т.п, корректно переизданных и на русском языке (те же Дейт,Конолли; но только не Ульман или Стоунбрейкер - они вообще из ООСУБД-лагеря и по определению мыслят "не как надо", разными способами дискредитируя все реляционное путем пропускания через свои объектно-ориентированные мозги и речевой аппарат)