|
Что такое НЕ УНИКАЛЬНЫЙ ключ???...
|
|||
---|---|---|---|
#18+
2 kondi Прочитал. Лишний раз убедился, что излишние упрощения рано или поздно приводят к путанице. Причем чем сильнее упрощение, тем быстрее возникает смешение понятий. Имхо, лучше сразу потратить лишнее время на изучение правильной реляционной теории , вернее, реляцонной теории в правильном изложении, чем потом разбираться с неразберихой в терминологии. 2 wara Словарь Ожегова - штука, конечно, хорошая. Но далеко не всегда применимая и удобная. Уникальность гораздо проще определяется так - вводится понятие операции сравнения "=". Дальше определение - набор элементов обладает свойством уникальности, для любого элемента A из набора и не существует такого элемента B, что выполняется условие A=B. Все очень просто. Если не вдаваться в детали, как определяется сама операция "=" Не помню точно, где это объяснялось. Если припрет - найду источник, конечно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2003, 22:20 |
|
Что такое НЕ УНИКАЛЬНЫЙ ключ???...
|
|||
---|---|---|---|
#18+
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сли это Вам не видно сразу, включите поиск и увидите что Репликант сказал "ключ" без какого-бы то нибыло уточнения о каком ключе идет речь. Все ясно: свои советы приберегите для себя - они вам гораздо нужнее! За свои слова отвечать надо, а не хочется, да? Или Вы это другой Репликант? Я за свои слова отвечаю и доказал это в очередной раз. Как насчет вас? И не надо передергивать насчет "другого" Репликанта Согласен я с Вами, но в учебной литературе говорят "ключ" а потом объясняют какими они бывают, вот и все. Что вместо словосочетания "потенциальный/первичный/внешний ключ" используется "ключ потенциальный потенциальный/первичный/внешний" и поэтому это вас смущает? Если же в самом тексте (а не в заголовке) вообще определяется термин "ключ" без чего-либо ("потенциальный" и т.д) или используется, а в контексте нет информации о том какой он ("потенциальный" и т.д), то это уже чистой воды отсебятина (интересно даже что это за Интернет-ресурс или книжка?) и учебной литературой это не является поскольку противоречит официальной реляционной теории, изложенной и основополагающей в многочисленных трудах-книжках Кодда,Бойса,Чамберлина,Чена,Навата,Дейта и т.д и т.п, корректно переизданных и на русском языке (те же Дейт,Конолли; но только не Ульман или Стоунбрейкер - они вообще из ООСУБД-лагеря и по определению мыслят "не как надо", разными способами дискредитируя все реляционное путем пропускания через свои объектно-ориентированные мозги и речевой аппарат) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2003, 23:25 |
|
|
start [/forum/search_topic.php?author=cub&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
259ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
others: | 446ms |
total: | 823ms |
0 / 0 |