|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
23.04.2012, 23:44 | #1 |
Форумчанин
Регистрация: 03.05.2010
Сообщений: 159
|
Дублирование полей в нескольких таблицах и их заполнение
Стал вопрос следующим образом
есть две таблицы , одна из них дублирует поля предыдущей из выше приведенной в необходимо чтоб при заполнении поля Socket остальные поля из первой таблицы заполнялись автоматически Можно конечно вручную прописать в событиях компонента того же ДбЛукАпКомбоБокс (ну по крайней мере так кажется) , но существует ли компонент который делал бы это или свойство в таблице ? |
24.04.2012, 12:57 | #2 |
Старожил
Регистрация: 20.04.2008
Сообщений: 5,526
|
нормализовать базу.
Выкинуть из второй таблицы все поля дублирующее первую. оставить только поле связи (идентификатоh ссылка на запись в первой таблице). тот самый lookup. для формирования второго Grid-a использовать либо представление (view) либо просто query +SQL с left/inner join иначе как только данные в первой таблице будут изменены. (к примеру заметили ОПЕЧАТКУ и скорректировали название). Во второй таблице имеем НЕВЕРНЫЕ данные.(опечатка не была исправлена). Можно конечно исправить и там НО их там много и кто об этом вспомнит. И наоборот заметили туже ОПЕЧАТКУ во второй таблице. Исправили одну строчку. но таких строк может быть много. а если еще эта опечатка невероятным образом оказалась совпавшей с ПРАВИЛЬНЫМ текстом НО для другого объекта. КАК разобраться где надо исправить, а где оставить.
программа — запись алгоритма на языке понятном транслятору
|
24.04.2012, 15:41 | #3 |
Форумчанин
Регистрация: 03.05.2010
Сообщений: 159
|
спасибо буду пробовать
|
24.04.2012, 16:16 | #4 | |
Форумчанин
Регистрация: 03.05.2010
Сообщений: 159
|
Цитата:
Что я выше и проделал с выше изложенными таблицами |
|
24.04.2012, 17:55 | #5 |
Форумчанин
Регистрация: 04.04.2009
Сообщений: 438
|
Вы хорошо излагаете теорию ссылочной целостности, но, к вашей беде, это всего лишь теория.
"Обычно в СУБД для реализации ссылочной целостности в дочерней таблице создают внешний ключ". А можно осведомиться что в вашей интерпретации означает "ссылочная целостность"? И при чем тут внешний ключ в "дочерней таблице"? Кто такой "дочерний таблица"? Неужто мы до сих пор не осознали, что нет в SQL СУБД никаких родительских, сыновних, дочерних и прочих таблиц. Все таблицы одноранговые и логика их взаимодействия зависит только от того что вы вложили в сущности структуры таблиц и какие запросы формируете для получения актуальных данных. Кто вам сказал, что "внешний ключ, ссылающийся на родительскую таблицу, и указывают вид каскадных воздействий"? (Набрался же терминов, определил бы уж что такое "каскадных воздействий") Во-первых, эти "каскадные воздействия" нужно еще определить в базе (не забыть). Т.е. чего эти "каскадные воздействия" там будут делать, а это очень даже конкретные "воздействия". Во-вторых, действия эти происходят на сервере СУБД. Вам очень нравиться, что кто-то за вашей спиной проделывает "разные действия" (да, определенные вами, но где-то там, на стороне)? FK - это шпион, который делает что-то что происходит за пределами вашего приложения. А проще, при наличии FK, контроль за действиями в базе данных у вас потерян. "В последующем СУБД сама при необходимости...". Вот ведь как: "сама". Шибко самостоятельная СУБД. Определяет чего надо человеку, то и делает. Спуститесь на землю. Никто за вас ничего делать не будет - давно известный и понятный факт. А то что СУБД удалит из таблицы данные, на которые ссылается другая таблица, по "всесильности" FK, так это частный случай, который выпячивать нет никакой необходимости из-за его малой значимости. Других существенных и очень нужных действий на FK повесить вряд ли получится. Если честно, создавали ли вы Foreign key, а, главное, как это облегчило вашу участь как разработчика базы данных? Спросите у себя, пожалуйста. |
24.04.2012, 19:26 | #6 | |
Форумчанин
Регистрация: 03.05.2010
Сообщений: 159
|
Цитата:
Относительно моей проблемы - она заключалась в тавтологии полей , что я в последствии и исправил . На доннам этапе , единственный минус каскадных воздействий - это недостаточность в обновлении отображаемых данных в компоненте , но это легко исправить проверкой состояния БД |
|
24.04.2012, 19:53 | #7 | |
Форумчанин
Регистрация: 03.05.2010
Сообщений: 159
|
Цитата:
Относительно моей проблемы - она заключалась в тавтологии полей , что я в последствии и исправил . На доннам этапе , единственный минус каскадных воздействий - это недостаточность в обновлении отображаемых данных в компоненте , но это легко исправить проверкой состояния БД |
|
24.04.2012, 20:26 | #8 |
Форумчанин
Регистрация: 26.03.2012
Сообщений: 665
|
То что вы пытались сделать в топике это так называемый естественный ключ.
Он хорош когда запись можно однозначно идентифицировать по минимальному количеству полей, в идеале одному и не сильно большому. И тогда каскадное обновление по такому ключу оправдано. В случае когда таких полей больше то естественный ключ заменяют на сурогатный, т.е. как уже было сказано, добавляют поле (например "счетчик"/автотинкремент, либо гуид, либо ...), и связь делают именно по нему. Последний раз редактировалось =master=; 25.04.2012 в 10:51. |
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Поиск совпадений в нескольких таблицах | Macklay | SQL, базы данных | 13 | 29.07.2011 15:06 |
Заполнение полей на сайте | redcouch | Общие вопросы C/C++ | 0 | 15.07.2010 22:00 |
Поиск данных в нескольких таблицах | a_n_n_a | БД в Delphi | 10 | 23.04.2010 11:33 |
Объеденение полей запроса в для отображения нескольких полей в одном списке | mrCreator | Microsoft Office Access | 3 | 08.08.2009 00:53 |