Дублирование полей в нескольких таблицах и их заполнение

[MIKE11IPME]

Стал вопрос следующим образом
есть две таблицы , одна из них дублирует поля предыдущей

из выше приведенной в

необходимо чтоб при заполнении поля Socket остальные поля из первой таблицы заполнялись автоматически

Можно конечно вручную прописать в событиях компонента того же ДбЛукАпКомбоБокс (ну по крайней мере так кажется) , но существует ли компонент который делал бы это или свойство в таблице ?

[evg_m]

нормализовать базу.
Выкинуть из второй таблицы все поля дублирующее первую.
оставить только поле связи (идентификатоh ссылка на запись в первой таблице). тот самый lookup.
для формирования второго Grid-a использовать либо представление (view) либо просто query +SQL с left/inner join

иначе как только данные в первой таблице будут изменены. (к примеру заметили ОПЕЧАТКУ и скорректировали название). Во второй таблице имеем НЕВЕРНЫЕ данные.(опечатка не была исправлена). Можно конечно исправить и там НО их там много и кто об этом вспомнит. И наоборот заметили туже ОПЕЧАТКУ во второй таблице. Исправили одну строчку. но таких строк может быть много. а если еще эта опечатка невероятным образом оказалась совпавшей с ПРАВИЛЬНЫМ текстом НО для другого объекта. КАК разобраться где надо исправить, а где оставить.

[MIKE11IPME]

спасибо буду пробовать

[MIKE11IPME]

Сообщение от evg_m

иначе как только данные в первой таблице будут изменены. (к примеру заметили ОПЕЧАТКУ и скорректировали название). Во второй таблице имеем НЕВЕРНЫЕ данные.(опечатка не была исправлена). Можно конечно исправить и там НО их там много и кто об этом вспомнит. И наоборот заметили туже ОПЕЧАТКУ во второй таблице. Исправили одну строчку. но таких строк может быть много. а если еще эта опечатка невероятным образом оказалась совпавшей с ПРАВИЛЬНЫМ текстом НО для другого объекта. КАК разобраться где надо исправить, а где оставить.

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

Что я выше и проделал с выше изложенными таблицами

[Скандербег]

Вы хорошо излагаете теорию ссылочной целостности, но, к вашей беде, это всего лишь теория.
"Обычно в СУБД для реализации ссылочной целостности в дочерней таблице создают внешний ключ".
А можно осведомиться что в вашей интерпретации означает "ссылочная целостность"? И при чем тут внешний ключ в "дочерней таблице"?
Кто такой "дочерний таблица"?
Неужто мы до сих пор не осознали, что нет в SQL СУБД никаких родительских, сыновних, дочерних и прочих таблиц. Все таблицы одноранговые и логика их взаимодействия зависит только от того что вы вложили в сущности структуры таблиц и какие запросы формируете для получения актуальных данных.

Кто вам сказал, что "внешний ключ, ссылающийся на родительскую таблицу, и указывают вид каскадных воздействий"?
(Набрался же терминов, определил бы уж что такое "каскадных воздействий")
Во-первых, эти "каскадные воздействия" нужно еще определить в базе (не забыть). Т.е. чего эти "каскадные воздействия" там будут делать, а это очень даже конкретные "воздействия".
Во-вторых, действия эти происходят на сервере СУБД.
Вам очень нравиться, что кто-то за вашей спиной проделывает "разные действия" (да, определенные вами, но где-то там, на стороне)?
FK - это шпион, который делает что-то что происходит за пределами вашего приложения. А проще, при наличии FK, контроль за действиями в базе данных у вас потерян.

"В последующем СУБД сама при необходимости...".
Вот ведь как: "сама". Шибко самостоятельная СУБД. Определяет чего надо человеку, то и делает.
Спуститесь на землю. Никто за вас ничего делать не будет - давно известный и понятный факт.
А то что СУБД удалит из таблицы данные, на которые ссылается другая таблица, по "всесильности" FK, так это частный случай, который выпячивать нет никакой необходимости из-за его малой значимости. Других существенных и очень нужных действий на FK повесить вряд ли получится.

Если честно, создавали ли вы Foreign key, а, главное, как это облегчило вашу участь как разработчика базы данных? Спросите у себя, пожалуйста.

[MIKE11IPME]

Сообщение от Скандербег

Вы хорошо излагаете теорию ссылочной целостности, но, к вашей беде, это всего лишь теория.

не излагал , а копипастил =) источник http://www.programmersclub.ru/bookdb/ можете с ним , а точнее с автором данной книги, оспаривать правильность выше изложенных мыслей
Относительно моей проблемы - она заключалась в тавтологии полей , что я в последствии и исправил .
На доннам этапе , единственный минус каскадных воздействий - это недостаточность в обновлении отображаемых данных в компоненте , но это легко исправить проверкой состояния БД

[MIKE11IPME]

Сообщение от Скандербег

Вы хорошо излагаете теорию ссылочной целостности, но, к вашей беде, это всего лишь теория.

не излагал , а копипастил =) источник можете с ним , а точнее с автором данной книги, оспаривать правильность выше изложенных мыслей
Относительно моей проблемы - она заключалась в тавтологии полей , что я в последствии и исправил .
На доннам этапе , единственный минус каскадных воздействий - это недостаточность в обновлении отображаемых данных в компоненте , но это легко исправить проверкой состояния БД

[=master=]

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