Dmitry Voroshin parix3-JGs/[EMAIL PROTECTED] wrote in message news:[EMAIL
PROTECTED]
Отсюда вывод: естественный ключ не может быть первичным ключём. Однако!...
Т.к. добавление искуственного ключа не ухудшает НФ
Oleg LOA wrote:
Dmitry Voroshin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Отсюда вывод: естественный ключ не может быть первичным ключём. Однако!...
Т.к. добавление искуственного ключа не ухудшает НФ
Он полуестественный :-D Сегменты-то искусственные
--
Regards. Ded.
Evgeny Putilin evgeneyputilin-JGs/[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Т.к. добавление искуственного ключа не ухудшает НФ
Какую именно? Наличие одновременно двух возможных ключей как раз одну из форм
нарушает.
Уточни какую ;-)
rstas wrote:
...
ПОФ
...
ПОЦО
...
ПОГИД
...
Вспоминается: Нет такого предмета, который не мог бы стать еврейской
фамилией ;-)
Дальше интересно, но первый абзац преодолел с трудом :-)
Nikolay Trifonov пишет:
Ну засинхронизировал ты ПОФ1 с ПОЦО, но потом эти же данные надо передать в
ПОФ1 и ПОФ2, как это делаешь?
у меня так:
1) филиалы передают друг другу только электронные накладные (чтобы
товар было проще приходовать)
2) из филиала в ЦО и обратно передаются
ПЕРВИЧНЫЙ КЛЮЧ НЕ ДОЛЖЕН НЕСТИ
КАКУЮ-ЛИБО СМЫСЛОВУЮ НАГРУЗКУ !!!
А если случайно получилось.
Завести еще одно поле, но уже без всякого смысла?
Тоды это естественный ключ :-)
Отсюда вывод: естественный ключ не может быть первичным ключём. Однако!...
Ну как в этот оутлуке увидеть емайл отправителя?
[dima та еще сАбака lcpi.lipetsk.ru]
Но лучше спрашивай здесь, на форуме.
Коваленко Дмитрий.
Kovalenko Dmitry [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Мда. А по мне так и просто Record_ID
достаточно. Естественней некуда :)))
ты про таблицы соответствия global_id - local_id забыл :-)
On Thu, 09 Nov 2006 22:01:15 +0300, Kovalenko Dmitry [EMAIL PROTECTED] wrote:
Я уж скока лет бубню, что самый естественный способ для реплицируемых
таблиц - двухсегментный PK (Base_ID, Record_ID).
Мда. А по мне так и просто Record_ID
достаточно. Естественней некуда :)))
+1.
В PK незачем
On Thu, 09 Nov 2006 22:52:45 +0300, Nikolay Trifonov [EMAIL PROTECTED] wrote:
Ты не прав (ИМХО), так как сложность почти всех запросов увеличивается и
намного
Тебе это только кажется, пока сам не попробуешь ;)
Такое разделение нужно, но вот в PK действительно не стоит запихивать BaseID.
Но
Nikolay Trifonov [EMAIL PROTECTED] сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
Ты не прав (ИМХО), так как сложность почти всех запросов увеличивается и
намного
Сложность запросов снижается.
Репликация (синхронизация) значительно упрощается.
Зато появляется информация для
Мда. А по мне так и просто Record_ID
достаточно. Естественней некуда :)))
ты про таблицы соответствия global_id - local_id забыл :-)
Ага, только не забыл, а закрысил :)
Коваленко Дмитрий.
Ты не прав (ИМХО), так как сложность почти всех запросов увеличивается и
намного
Сложность запросов снижается.
Репликация (синхронизация) значительно упрощается.
Зато появляется информация для группировки.
Проверено на:
зеваю
- Репликация слиянием?
- Как насчет маштабирования,
Kovalenko Dmitry [EMAIL PROTECTED]
сообщил/сообщила в новостях следующее:
news:[EMAIL PROTECTED]
- Репликация слиянием?
Ни в коем случае. Каждому только, то что его касается.
Репликация синхронизацией справочников (всем все),
обменом:
документы (кому какие - ID базы),
журналы продаж (кому
Kovalenko Dmitry wrote:
Мда. А по мне так и просто Record_ID
достаточно. Естественней некуда :)))
ты про таблицы соответствия global_id - local_id забыл :-)
Ага, только не забыл, а закрысил :)
Да лана тебе. Двухсегментный PK - это, по сути, завуалированный 1:n
с
Для данных, информация о принадлежности которых к базам имеет смысловое
значение, используемое в деятельности центра (документы, скажем)
двухсегментный PK эффективнее.
Убей себя ап стену.
Если тебе нужно знать какому филиалу
принадлежит документ, то это нужно
оформить явно, в виде отдельных
ArtGal wrote:
Ни в коем случае. Каждому только, то что его касается.
Его зевки - от специфичной предметной области (учёт недвижимости).
Он обслуживает фактически не деятельность (процесс), а регистрацию
статики конечного автомата и переходов его из одного состояния в другое.
Ну а
- Репликация слиянием?
Ни в коем случае. Каждому только, то что его касается.
Уровни системы увеличиваются непросто. Потребуется 2-3 дня.
Меня вот что во всех этих схемах
напрягает - так это их хрупкость и
ограниченность.
1. Захочешь слияние - хрен тебе.
2. Захочешь завести новую базу
Ded писал(а):
Kovalenko Dmitry wrote:
Убей себя ап стену.
Не, это не мой способ. Лобные кости слишком крепкие. Я на
потенциально возможный случай крайней необходимости другой способ
придумал, поприятнее.
:BEER:
Коваленко Дмитрий.
PS. Блин, я так хотел встретить тебя на
московской
Hello,
Kovalenko Dmitry said the following on 10.11.2006 11:20:
- Репликация слиянием?
- Как насчет маштабирования, например, числа уровней системы?
Ты бы статью написал, что ли... ;-)
--
Oleg
1. Захочешь слияние - хрен тебе.
При наличии ID записи, ID базы, Parent_ID базы
это делается просто слиянием.
А что такое Parent_ID базы ?
Это ID записи или ID базы ?
Коваленко Дмитрий.
PS. Thanks :)
Kovalenko Dmitry wrote:
PS. Блин, я так хотел встретить тебя на
московской тусовке :(
Да я бы тоже с удовольствием, но у меня долгожданный отпуск висел на
волоске. Как всегда вовремя очередное хватай мешки, вокзал уходит
случилось, недели три без выходных по 14 часов пахал.
--
- Репликация слиянием?
- Как насчет маштабирования, например, числа уровней системы?
Ты бы статью написал, что ли... ;-)
Про репликацию? Сгинь, проклятый.
Я про первичные ключи в свете
репликации пока писал, чуть не опух :)
http://www.rsdn.ru/File/84/primary_keys_and_replication.zip
ты про таблицы соответствия global_id - local_id забыл :-)
Может, ты хотел сказать base1.local_id != base2.local_id ?
Не, он имел в виду мою таблицу, в
которой для каждого local_id указан
внешний идентификатор
Внешний (ну или глобальный)
идентификатор - это BaseID+LocalID
Потому как
Oleg Deribas [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Hello,
Kovalenko Dmitry said the following on 10.11.2006 11:20:
- Репликация слиянием?
- Как насчет маштабирования, например, числа уровней системы?
Ты бы статью написал, что ли... ;-)
Статья давно написана. Дима
Kovalenko Dmitry wrote:
PS. Так и не сказал тогда DED'у спасибо.
Вот такой я мерзавец :-)
Да я тебе тогда не особо и помог. У меня осталось впечатление, что
мы с тобой тогда малость на разных языках говорили, как за нами
частенько водится :)
--
Regards. Ded.
Kovalenko Dmitry [EMAIL PROTECTED]
сообщил/сообщила в новостях следующее:
news:[EMAIL PROTECTED]
А что такое Parent_ID базы ?
Прикалываешься?
Parent_ID это ID базы отделния, которое является объединением
нескольких розничных подразделений.
Справочник аптек и отделений - есть список баз.
ID
Kovalenko Dmitry [EMAIL PROTECTED]
сообщил/сообщила в новостях следующее:
news:[EMAIL PROTECTED]
ПЕРВИЧНЫЙ КЛЮЧ НЕ ДОЛЖЕН НЕСТИ
КАКУЮ-ЛИБО СМЫСЛОВУЮ НАГРУЗКУ !!!
А если случайно получилось.
Завести еще одно поле, но уже без всякого смысла?
8-)
--
С уважением,
Артур Галимов. ФК
А что такое Parent_ID базы ?
Прикалываешься?
Да нет, вроде.
Parent_ID это ID базы отделния, которое является объединением
нескольких розничных подразделений.
Справочник аптек и отделений - есть список баз.
ID Parent_ID Name
0 0 Предприятие (база 0)
1 0 Отделение 1
Kovalenko Dmitry wrote:
хотим увидеть
здесь только одного Иванова, а не двух
... Прости LOA, я не специально :)
Ващета имхо если б их было два, FB было бы только лучче :-D
--
Regards. Ded.
Ты бы статью написал, что ли... ;-)
Статья давно написана. Дима ты её до публикуемого состояния доводил?
Дык это, того. Если чего не так -
доводите и публикуйте.
Главное соблюдайте основные правила
русского языка - в жо.у пишется
раздельно, а нах.р слитно.
Коваленко Дмитрий.
WildSery wrote:
Этот ID нужен только для репликации :)
В центральной базе - вполне нужен
ArtGal wrote:
А если случайно получилось.
Завести еще одно поле, но уже без всякого смысла?
Разумеется! и заполнять случайными числами
ArtGal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Kovalenko Dmitry [EMAIL PROTECTED]
сообщил/сообщила в новостях следующее:
news:1163152933.069029.273230-kgokzNqkTZsvLoKJ9UdeTWB/[EMAIL PROTECTED]
ПЕРВИЧНЫЙ КЛЮЧ НЕ ДОЛЖЕН НЕСТИ
КАКУЮ-ЛИБО СМЫСЛОВУЮ НАГРУЗКУ !!!
А если
Ded [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Kovalenko Dmitry wrote:
хотим увидеть
здесь только одного Иванова, а не двух
... Прости LOA, я не специально :)
Ващета имхо если б их было два, FB было бы только лучче :-D
Ну вотопять в попугаях сосчитали :-):-):-)
То есть - создаем Иванова там и там.
Потом реплицируем сюда и хотим увидеть
здесь только одного Иванова, а не двух
... Прости LOA, я не специально :)
А вот бывает у тебя такие ситуации:
Тут ввели Иванова, и там ввели Иванова, но пока еще непонятно один ли это
Иванов или два. Произошла
Мадорский Г.В. wrote:
А вот бывает у тебя такие ситуации:
Тут ввели Иванова, и там ввели Иванова, но пока еще непонятно один ли
это Иванов или два. Произошла репликация. Cколько у тебя окажется Ивановых?
Репликация такого рода данных, требующих именно таблицы
соответствия, невозможна на
То есть - создаем Иванова там и там.
Потом реплицируем сюда и хотим увидеть
здесь только одного Иванова, а не двух
... Прости LOA, я не специально :)
А вот бывает у тебя такие ситуации:
Тут ввели Иванова, и там ввели Иванова, но пока еще непонятно один ли это
Иванов или два.
Nikolay Trifonov пишет:
Сорри, но начну новый пост, ОЕ заглючил.
один вопрос у меня в голове не укладывается: есть таблица CHANGES, в которой
для репликации записываются в какой строчке что изменилось триггером:
Сразу извиняюсь за размер поста, но
коротко тут не скажешь...
вопрос
Kovalenko Dmitry wrote:
То есть - создаем Иванова там и там.
Одного нужно будет грохнуть. Мда.
Олежка, ты там пригнись на всякий пожарный.
--
Regards. Ded.
разруливании некоторых конфликтов должен принимать участие ЛПР. Если
забыл курс АСУ - это Лицо, Принимающее Решение :)
Не знал и забыл :)
Меня в школе математикой шпинговали.
Я её тоже всю напрочь, благополучно
забыл. Точнее её вытеснили безумные
мысли об объектной базе и компонентном
KD Одного нужно будет грохнуть. Мда.
ненадо грохать ниодного. Иванов то чем виноват?
И так сметность большая.
--
Кочмин Александр
KD Одного нужно будет грохнуть. Мда.
ненадо грохать ниодного. Иванов то чем виноват?
И так сметность большая.
Не, я против. Дублеры - ЗЛО.
Со смертностью нужно бороться по
другому - нехер в конфе часами висеть,
займись действительно стоЯщим делом
:)))
Коваленко Дмитрий.
Kovalenko Dmitry пишет:
Дык это, того. Если чего не так -
доводите и публикуйте.
Главное соблюдайте основные правила
русского языка
Учтут!
Я вот только удивлен, почему до сих пор никто не опубликовал?!
Я к таким же выводам сам в своем корыте плыл мучительно долго. А прочитал бы
раньше -
On Fri, 10 Nov 2006 15:10:27 +0300, Ded [EMAIL PROTECTED] wrote:
Ващета имхо если б их было два, FB было бы только лучче :-D
Только в случае, если их никто не слил репликацией в одного :)
--
Сергей Смирнов.
Kovalenko Dmitry [EMAIL PROTECTED]
сообщил/сообщила в новостях следующее:
news:[EMAIL PROTECTED]
в виду ситуацию независимого создания
идентичных объектов в филиальных
базах, которые (после репликации) в
центральной базе будут представлены
ровно одним объектом (хорошо, одной
записью).
On Fri, 10 Nov 2006 15:23:57 +0300, Konstantin R. Beliaev [EMAIL PROTECTED]
wrote:
В центральной базе - вполне нужен
Согласен. Но ответ не полный.
В центральной базе у меня свои PK.
И ID базы в него не входит. Это всего лишь поле дополнительное. Ну с индексом,
как же без него.
--
Сергей
Ващета имхо если б их было два, FB было бы только лучче :-D
Хм, вообще говоря, FB на пользу пойдет
клонирование Еманова и Хорсуна ;)
Ну или, по крайней мере, кормить их
по-лучше что-ли, чтобы они стали
ПО-БОЛЬШЕ :)))
Коваленко Дмитрий.
Kovalenko Dmitry [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Со смертностью нужно бороться по
другому - нехер в конфе часами висеть,
займись действительно стоЯщим делом
:)))
У вообще-то уже двое :-):-):-)
Kovalenko Dmitry [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Хм, вообще говоря, FB на пользу пойдет
клонирование Еманова и Хорсуна ;)
Ну или, по крайней мере, кормить их
по-лучше что-ли, чтобы они стали
ПО-БОЛЬШЕ :)))
Нафиг клонировать - достаточно денег и толкового менеджера
On Fri, 10 Nov 2006 17:30:10 +0300, Kovalenko Dmitry [EMAIL PROTECTED] wrote:
Хм, вообще говоря, FB на пользу пойдет
клонирование Еманова и Хорсуна ;)
insert into FB_Developers (id, name)
select gen_id(gen_id_develop, 1), name
from FB_Developers
where (name like 'Еманов' or name
Kovalenko Dmitry wrote:
Не, я против. Дублеры - ЗЛО.
Коваленко Дмитрий.
Дык, всем известно что Дмитрий Коваленко и Коваленко Дмитрий - это
совсем разные люди ;-)
Вырва Валерий Евгеньевич wrote:
А почему бы не вставлять информацию о том от куда пришло обнавление?
Я уж скока лет бубню, что самый естественный способ для реплицируемых
таблиц - двухсегментный PK (Base_ID, Record_ID). Группировки-фильтрации
и прочая в отчётах всяких потом делаются
А почему бы не вставлять информацию о том от куда пришло обнавление?
Я уж скока лет бубню, что самый естественный способ для реплицируемых
таблиц - двухсегментный PK (Base_ID, Record_ID).
Мда. А по мне так и просто Record_ID
достаточно. Естественней некуда :)))
Коваленко Дмитрий.
Из филиала 1 пришел пакет с репликацией. Он загрузился в базу и этот же
пакет отправился в филиалы 2,3,4 ...?
В пакете содержится один источник назначения. Это первые 3 цифры имени файла
пакета.
Надо как-то загрузить данные в базу, похоже надо делать похожий триггер с
REPL3 и еще один с
Мда. А по мне так и просто Record_ID
достаточно. Естественней некуда :)))
А поподробнее? ;)
_
С уважением, Юрий
И вот в эту схему надо как-то вписать что данные из
второго филиала (REPL2) должны получить третий (я так понимаю надо делать
REPL3?) и четвертый.(надо REPL4 ?), а данные из третьего во второй и
четвертый, из четвертого во второй и третий. И как раз работу с этими
REPL2, REPL3 и REPL4 надо
Tonal wrote:
Можно совсем просто:
В центре всегда формируется файл для всех.
В данных указывается кто последний их изменил.
А в филиале свои изменения игнорируются.
Ну, тут получается 2 постулата:
а) в филиале данные от REPL в лог изменений не попадают в принципе
б) в центре обязательно
INSERT INTO CHANGES2(TABLEKEY,TABLENAME,OP,LOC_ID)
SELECT бла-бла-бла
FROM REPL_TABLES2 WHERE TABLENAME=DOCUMENTS;
[большие, круглые глаза]
конектимся к базе через sysdba, апдейтим DOCUMENTS, данные об этом попадают
в changes, на этом этапе все ок.
Реплицируем данные:
Nikolay Trifonov wrote:
Реплицируем данные: коннектимся как REPL2 и в DOCUMENTS делаем изменения.
Соответственно в триггер они не попадают.
Теперь то, что у меня не укладывается в голове: КАК ДОБАВИТЬ В ЭТУ СХЕМУ
ТРЕТЬЮ ТОЧКУ СИНХРОНИЗАЦИИ ? Растолкуйте непонятливому, плз.
Если мой ТЛ
имеются в виду базы данных
PS. Ночью надо спать, а не охинеей заниматься :)
Что делать если сроки...
Понятно. На скорую руку - предлагаю
сразу убить себя ап стену
Вечером попытаюсь вникнуть в твою
проблему.
Коваленко Дмитрий.
Nikolay Trifonov wrote:
дык это понятно, в голове не укладывается другое: если мы сделали
синхронизацию под учетной записью REPL2, то как сделать чтобы данные попали
в Changes для синхронизации с третьей, четвертой и т.д. базами. Немного в
голове это не укладывается, а английские доки еще
Я тут писал, писал. Потому стер.
Вопрос - у тебя для каждой базы выделен
свой диапазон значений генераторов?
Коваленко Дмитрий.
Вопрос - у тебя для каждой базы выделен
свой диапазон значений генераторов?
естественно свой
Спасибо.
Коваленко Дмитрий.
Здравствуйте, Nikolay.
Вы писали 7 ноября 2006 г., 23:22:38:
Konstantin R. Beliaev [EMAIL PROTECTED] wrote in
message news:[EMAIL PROTECTED]
Да, двухнаправленная. Но к счастью все базы удаленных точек синхронизируются
только через центральный офис. ХП не проходит, единственный вариант
Nikolay Trifonov пишет:
Если данные импортируются из филиала (логин REPL2), то данные в CHANGES не
попадут, так как установлена проверка IF( USER 'REPL2' ) THEN. И вот в
эту схему надо как-то вписать что данные из второго филиала (REPL2)
должны получить третий (я так понимаю надо делать
Nikolay Trifonov [EMAIL PROTECTED] сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
Теперь то, что у меня не укладывается в голове: КАК ДОБАВИТЬ В ЭТУ СХЕМУ
ТРЕТЬЮ ТОЧКУ СИНХРОНИЗАЦИИ ? Растолкуйте непонятливому, плз.
А что такое третья точка?
67 matches
Mail list logo
