Родительские и дочерние таблицы
На страницу Пред. 1, 2, 3 След.
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
yaffil
Профи
Вступление в Клуб: 18.08.2011
|
 Вт Янв 22, 2013 08:35 |
 |
Полезность: Нет оценки
|
| Random пишет: |
Соответствие реквизитов модели и столбцов в таблице можно посмотреть на закладке "Таблица" при просмотре класса.
Переименовывал, наверное, реквизиты? Рекомендую перестроить обе таблицы, родительскую и дочернюю. |
Там смотрел - всё красиво. Ничего не переименовывал, с 0 ручками создавал 
Перестроил родительскую таблицу - всё заработало. Мерси огромное! |
|
 |
yaffil
Профи
Вступление в Клуб: 18.08.2011
|
| Вт Янв 22, 2013 09:06 Re: Родительские и дочерние таблицы |
|
Полезность: Нет оценки
|
| Random пишет: |
А затем, что таково свойство родительских таблиц.
Говорю ж, в дочерней табличке есть констрейнт на родительскую.
Например, посмотри у клиентов.
Есть клиент. Абстрактный клиент, непонятно, банк или физик.
У банка не может быть ФИО, у клиента - SWIFT-кода. Но у того и другого есть дата заведения клиента в базе.
Физик и Банк - потомки одного родительского класса Клиенты. Идентификатор Физика (значение поля id таблицы z#cl_priv) должен присутствовать в поле id таблицы z#client согласно констрейнту FK_Z#CL_PRIV_ID. Должен и точка.
|
Так и у меня аналогично получается, что у таблиц 1-41 все обязаны иметь ссылку на клиента + одинаковый ID выгрузки по клиенту. Дополнительно имеют кучу своих собственных реквизитов (форматы выгрузки). Или я чего то не догоняю, в чём отличия?
| Random пишет: |
Соответсвенно, в дочернюю таблицу нельзя вставить данные, не вставив их предварительно в родительскую таблицу, и наоборот, удалить из родительской, не удалив из дочерней, нельзя.
Кроме того, если удалять данные только из дочерней, не удаляя из родительской, будет то самое "неконсистентное" удаление, за последствия такого действия... короче, я хз что случится. Как самое малое, системные вьюшки перестанут работать.
|
Уболтал Могу предположить, что через делете дочерней таблицы чистится всё в дочерней, а в родительской остается мусор от этих удалений (проверить не могу, нет доступа через какой нибудь SQL навигатор т.к. база на аутсорте). Как бэ ничего страшного, но не красиво и засирается табличное пространство. Просто хотелось меньше писанины. Переделаю на update, смысел в том, что мне надо занулить (сбросить) 41 параметр из 43 (2 из родительской их нужно тогда оставить). Есть способ присвоить 41 параметру NULL, а 2 не трогать? Кроме как просто в update set их все перечислить.
| Random пишет: |
| yaffil пишет: |
Собственно оно так и предполагается. Предлагаешь делать всё независимыми справочниками?
|
Предлагаю.
|
Ну так это же не красиво в словаре данных. ЦФТ испугаются увидев столько справочников И кроме того во всех 41 таблицах придётся создавать 2 одинаковых реквизита (ссылку на клиента и ИД выгрузки по клиенту). Собственно, судя по коду SQL из вышеприведённого это 2 независимых таблицы связанные первичным ключом (id). На скорости не особо должно сказаться. А удобство на лицо. Или всё таки плодить 41 справочник отдельно? Запутался 
| Random пишет: |
ХД = Хранилище Данных |
Угу, надо импортить данные в аналитическую систему. По её форматам. А эта система, почему то не умеет (или не хочет) сама определять были ли какие то изменения в клиенту. Ей видите ли только изменённые данные с последней выгрузки подавай. Ссылаются что типа производительнось просядет у них. А типа, то что в этом случае все вычисления в АБС придётся производить и жрать ресурсы боевого сервака, который более приоритетен, чем аналитический - их не волнует.  |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Ср Янв 23, 2013 05:42 Re: Родительские и дочерние таблицы |
|
Полезность: Нет оценки
|
| yaffil пишет: | | Random пишет: |
А затем, что таково свойство родительских таблиц.
Говорю ж, в дочерней табличке есть констрейнт на родительскую.
Например, посмотри у клиентов.
Есть клиент. Абстрактный клиент, непонятно, банк или физик.
У банка не может быть ФИО, у клиента - SWIFT-кода. Но у того и другого есть дата заведения клиента в базе.
Физик и Банк - потомки одного родительского класса Клиенты. Идентификатор Физика (значение поля id таблицы z#cl_priv) должен присутствовать в поле id таблицы z#client согласно констрейнту FK_Z#CL_PRIV_ID. Должен и точка.
|
Так и у меня аналогично получается, что у таблиц 1-41 все обязаны иметь ссылку на клиента + одинаковый ID выгрузки по клиенту. Дополнительно имеют кучу своих собственных реквизитов (форматы выгрузки). Или я чего то не догоняю, в чём отличия?
|
Ну так эти поля не уникальные, а я говорю про уникальный идентификатор записи, PK, который должен быть одинаковым в дочке и родителе.
Ну вставка получается такая:
| Код: |
insert into Z#PARENT(id, тра-ля-ля) values(seq_id.nextval, остальные поля) returning id into переменная;
insert into Z#CHILD(id, ещё поля) values(та самая переменная, и ещё значения полей);
|
это вместо одного инсерта
insert into Z#CHILD(id, все поля) values(seq_id.nextval, и все значения полей);
То же самое про удаление, хотя с удалением проще.
Хотя... вот вырастет объём данных, так у тебя будет задел, куда оптимизировать в смысле скорости. И банк уже подсядет на систему, и ЦФТ смирится...
| yaffil пишет: | | Random пишет: |
Соответсвенно, в дочернюю таблицу нельзя вставить данные, не вставив их предварительно в родительскую таблицу, и наоборот, удалить из родительской, не удалив из дочерней, нельзя.
Кроме того, если удалять данные только из дочерней, не удаляя из родительской, будет то самое "неконсистентное" удаление, за последствия такого действия... короче, я хз что случится. Как самое малое, системные вьюшки перестанут работать.
|
Уболтал Могу предположить, что через делете дочерней таблицы чистится всё в дочерней, а в родительской остается мусор от этих удалений (проверить не могу, нет доступа через какой нибудь SQL навигатор т.к. база на аутсорте). Как бэ ничего страшного, но не красиво и засирается табличное пространство. Просто хотелось меньше писанины. Переделаю на update, смысел в том, что мне надо занулить (сбросить) 41 параметр из 43 (2 из родительской их нужно тогда оставить).
|
Ну вот если удалять через операцию DELETE#AUTO, то операция чистит родительскую табличку сама (и заодно кушает ресурсы). А если писать delete d in ::[CHILD] where id = 123, то в родительской ничего само не почистится, будет предупреждение "Возможно неконсистентное удаление".
| yaffil пишет: | Есть способ присвоить 41 параметру NULL, а 2 не трогать? Кроме как просто в update set их все перечислить.
|
Я б завёл ещё одно поле "Признак удалённой записи", наверное.
update выполняется быстрее чем delete, а по помеченным записям в момент, когда системой не пользуются, по джобу можно потихоньку удалять данные
И чхать на производительность
| yaffil пишет: |
| Random пишет: |
| yaffil пишет: |
Собственно оно так и предполагается. Предлагаешь делать всё независимыми справочниками?
|
Предлагаю.
|
Ну так это же не красиво в словаре данных. ЦФТ испугаются увидев столько справочников И кроме того во всех 41 таблицах придётся создавать 2 одинаковых реквизита (ссылку на клиента и ИД выгрузки по клиенту). Собственно, судя по коду SQL из вышеприведённого это 2 независимых таблицы связанные первичным ключом (id). На скорости не особо должно сказаться. А удобство на лицо. Или всё таки плодить 41 справочник отдельно? Запутался
|
ЦФТ не испугаются. Им по барабану. Завёл 41 справочник, платишь за 41 справочник
И не важно, что 40 - это дочерние, а 1 - родительский. Наоборот, один справочник можно выкинуть, будет экономия... наверное. ))
Я, когда выгрузки в ЦФТ-шное ХД делал, тоже думал заводить родительский тип и кучу дочерних. Потом передумал, сделал просто кучу справочников (около ста).
Теперь вовсе снёс справочники, оставил только таблицы, работа через динамический SQL.
Это и не локальные доработки, за них платить не надо, и в словаре данных не мешаются, и по скорости хорошо. И ещё вкусности есть.
| yaffil пишет: |
| Random пишет: |
ХД = Хранилище Данных |
Угу, надо импортить данные в аналитическую систему. По её форматам. А эта система, почему то не умеет (или не хочет) сама определять были ли какие то изменения в клиенту. Ей видите ли только изменённые данные с последней выгрузки подавай. Ссылаются что типа производительнось просядет у них. А типа, то что в этом случае все вычисления в АБС придётся производить и жрать ресурсы боевого сервака, который более приоритетен, чем аналитический - их не волнует. |
1. Выгрузка из АБС в формате csv есть в ЦФТ.
2. Работает она на разнице между тем, что получилось сейчас и тем, что выгружалось раньше (всё хранится в АБС)
3. есть способ анализировать только поля id, sn, su, но может не всегда сработать
4. пробивать в ЦФТ, чтобы в дополнение к полям sn и su было добавлено st (serial time) или tt (transaction time) - астрономические дата и время обновления записи.
ну или значение из отдельного общего для всех таблиц сиквенса
5. или строить выгрузки на LogMiner, Streams и иже с ними. |
|
|
yaffil
Профи
Вступление в Клуб: 18.08.2011
|
| Ср Янв 23, 2013 08:19 |
|
Полезность: Нет оценки
|
Таблицы без справочников - это хорошо, но когда нет доступа к БД, а только к интерфейсной части ЦФТ, то выбирать не приходится.
А что за выгрузка? И каким образом она сравнивает предыдущие значения?
Я хотел сначала к аудиту зацепиться, но подумал что устанешь ждать, потому на справочники переориентировался 1 справочник 1 таблица импорта в нужном формате. Сначала цикл по клиентам заполняет/апдейтит все справочники. Затем цикл по самому справочнику с выплёвыванием в файл нужной инфу по новым клиентам или по тем, у кого что то поменялось. |
|
|
SS
Участник
Вступление в Клуб: 25.01.2013
|
| Пт Янв 25, 2013 14:03 |
|
Полезность: Нет оценки
|
Коллеги, а почему не использовать GoldenGate?
Вы пытаетесь заново изобрести колесо. |
|
|
yaffil
Профи
Вступление в Клуб: 18.08.2011
|
| Пт Янв 25, 2013 17:06 |
|
Полезность: Нет оценки
|
Потому, что:
1. оно я полагаю не бесплатное
2. Если есть система в которую надо выгрузить данные в нужных форматах, зачем использовать промежуточное звено?
3. Данный формат (с промежуточным звеном) был бы актуален, если скажем, есть несколько систем со своими форматами в которые надо закачивать данные. Тогда, да, тупо заливаем весь срез туда, а от туда уже обрабатываем различными операциями. И пусчай оно там ресурсы тратит. |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Пн Янв 28, 2013 16:11 |
|
Полезность: Нет оценки
|
| SS пишет: | Коллеги, а почему не использовать GoldenGate?
Вы пытаетесь заново изобрести колесо. |
Я пытался прикрутить GG, и пытаюсь до сих пор, но есть причины, по которым это достаточно сложно.
А вот для себя лично: поделитесь опытом настройки GG чтоб вывод был во flat-files? |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Пн Янв 28, 2013 16:16 |
|
Полезность: Нет оценки
|
| yaffil пишет: | | Таблицы без справочников - это хорошо, но когда нет доступа к БД, а только к интерфейсной части ЦФТ, то выбирать не приходится. |
То есть нет доступа к АРМ Администратор?
| yaffil пишет: | | А что за выгрузка? И каким образом она сравнивает предыдущие значения? |
Выгрузка... это процесс получения новых/измененных/потерявших актуальность данных.
select * from dual
minus
select * from cache_dual;
и наоборот
select * from cache_dual
minus
select * from dual;
После того, как данные на руках, их нужно запихнуть в cache_dual, понятно. |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Пн Янв 28, 2013 16:17 |
|
Полезность: Нет оценки
|
| yaffil пишет: | Потому, что:
1. оно я полагаю не бесплатное |
Естественно
| yaffil пишет: | | 2. Если есть система в которую надо выгрузить данные в нужных форматах, зачем использовать промежуточное звено? |
Увеличение производительности. Снижение нагрузки на АБС.
| yaffil пишет: | | 3. Данный формат (с промежуточным звеном) был бы актуален, если скажем, есть несколько систем со своими форматами в которые надо закачивать данные. Тогда, да, тупо заливаем весь срез туда, а от туда уже обрабатываем различными операциями. И пусчай оно там ресурсы тратит. |
И так тоже можно. |
|
|
yaffil
Профи
Вступление в Клуб: 18.08.2011
|
| Пн Янв 28, 2013 16:44 |
|
Полезность: Нет оценки
|
| Random пишет: |
То есть нет доступа к АРМ Администратор?
|
Только туды и есть, но там создаются объекты схемы, за которые надо платить А если, например через Девелопер или SQL навигатор какой-нибудь создавать таблицы, то за них платить не надо.
З.Ы. все вроде нормально отрабатывает с такой структурой и довольно таки быстро. |
|
|
yaffil
Профи
Вступление в Клуб: 18.08.2011
|
| Ср Янв 30, 2013 08:08 |
|
Полезность: Нет оценки
|
| Код: |
delete x in ::[FIS_EXPORT];
|
Правильно понимаю, что, если это дочерняя таблица, то правильно удалять данные в ней из родительской вот так:
| Код: |
delete x in ::[РОДИТЕЛЬ] where x%class='FIS_EXPORT';
|
В этом случае вычистится и дочерняя полностью и родительская в части связанных данных с дочерней |
|
|
devor
Профи
Вступление в Клуб: 13.02.2012
|
| Ср Янв 30, 2013 08:39 |
|
Полезность: 1
|
| yaffil пишет: |
Правильно понимаю, что, если это дочерняя таблица, то правильно удалять данные в ней из родительской вот так:
| Код: |
delete x in ::[РОДИТЕЛЬ] where x%class='FIS_EXPORT';
|
В этом случае вычистится и дочерняя полностью и родительская в части связанных данных с дочерней |
Неправильно. При ручном удалении нужно чистить как родительскую таблицу, так и дочернюю отдельно. |
|
|
yaffil
Профи
Вступление в Клуб: 18.08.2011
|
| Ср Янв 30, 2013 08:47 |
|
Полезность: Нет оценки
|
Печалька
Т.е. оба этих delete писать друг за дружкой? |
|
|
devor
Профи
Вступление в Клуб: 13.02.2012
|
| Ср Янв 30, 2013 08:54 |
|
Полезность: Нет оценки
|
| yaffil пишет: | Печалька
Т.е. оба этих delete писать друг за дружкой? |
Да.
Либо, как вариант, можно использовать интерфейсный пакет (если таблица в словаре Платформы(создана в Админе словаря)):
| Код: |
declare
i integer;
begin
i:=rtl.open;
for obj in (select id from Z#FIS_EXPORT)
loop
Z#FIS_EXPORT#INTERFACE.delete(obj.id);
end loop;
end;
|
Еще можно триггер на удаление повесить. Но этот вариант не очень хорош, т.к. ненагляден (как мне кажется). |
|
|
yaffil
Профи
Вступление в Клуб: 18.08.2011
|
| Ср Янв 30, 2013 10:41 |
|
Полезность: Нет оценки
|
А так тоже самое будет?:
| Код: |
for (FIS_EXPORT_DEL in ::[FIS_EXPORT] where FIS_EXPORT_DEL.[CREDIT_ID] in (1,2,7,9)
)loop
::[FIS_EXPORT].[DELETE_AUTO];
end loop;
|
Т.е. удалятся все записи с CREDIT_ID in (1,2,7,9), а остальные остануться. |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
