On Fri, 29 Dec 2006 10:23:16 +0300, Oleg LOA <[EMAIL PROTECTED]> wrote:
>>> Угу. Мне тут для внесения денег на свой счёт потребовали непременно
>>> почтовый индекс своего проживания указать :(
>>> Скажите, зачем для конвертации рублей в доллары нужен почтовый индекс?
>> Они на него делят. Курс те
"Konstantin R. Beliaev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL
PROTECTED]
>
> WildSery wrote:
>> Угу. Мне тут для внесения денег на свой счёт потребовали непременно почтовый
>> индекс своего проживания указать :(
>> Скажите, зачем для конвертации рублей в доллары нужен почтовый индекс?
WildSery wrote:
Угу. Мне тут для внесения денег на свой счёт потребовали непременно почтовый
индекс своего проживания указать :(
Скажите, зачем для конвертации рублей в доллары нужен почтовый индекс?
Они на него делят. Курс теперь такой ;-) для "из рублей в доллары".
"Vladimir A.Bakhvaloff" <[EMAIL PROTECTED]>
сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED]
>
> А просто УДФ, которая посмотрит time_zone_information на серваке, и из
> текущего времени вычтет соотв. смещение?.. /это я бэз приколов/
>
Посмотреть она (УДФ) посмотрит.
А вот как оп
On Wed, 27 Dec 2006 18:43:59 +0300, Ded <[EMAIL PROTECTED]> wrote:
> Вызвать удф, которая позвонит в Гринвич и поинтересуеццо... :)
Не подходит. В многопользовательской работе слишком много телефонных линий
одновременно нужно.
--
Сергей Смирнов.
WildSery wrote:
On Wed, 27 Dec 2006 18:11:19 +0300, Boulitchev Aleksey <[EMAIL PROTECTED]>
wrote:
время по гринвичу не прыгает :)
А как изнутри базы FB получить время по гринвичу? (вопрос не о той программе,
конечно же)
Вызвать удф, которая позвонит в Гринвич и поинтересуеццо... :)
On Wed, 27 Dec 2006 18:11:19 +0300, Boulitchev Aleksey <[EMAIL PROTECTED]>
wrote:
> время по гринвичу не прыгает :)
А как изнутри базы FB получить время по гринвичу? (вопрос не о той программе,
конечно же)
--
Сергей Смирнов.
Когда был переход с летнего времени на
зимний, я выгреб тонну сообщений об
ошибке работы программы, которая
запускалась каждые десять минут для
создания списка процессов, работающих
на сервере.
Автор этой программулины был
неприятно удивлен существованием
ситуации, когда время на вполне
законны
> >> > PS. IBP v3 - это мой шатл :-)
>
> к слову о шаттлах
>
> в общем нет в мире совершенства (с) Маленький принц
Когда был переход с летнего времени на
зимний, я выгреб тонну сообщений об
ошибке работы программы, которая
запускалась каждые десять минут для
создания списка процессов, работающих
> PS. IBP v3 - это мой шатл :-)
к слову о шаттлах
http://spacenews.ru/spacenews/live/full_news.asp?id=19198
к правильно написанной программе прилагаются правильные условия
использования и правильные пользователи
в общем нет в мире совершенства (с) Маленький принц
--
Булычев Алексей
http:
WildSery пишет:
On Tue, 26 Dec 2006 17:43:37 +0300, Tonal <[EMAIL PROTECTED]> wrote:
Единственное возражение - слияние данных, когда по одинаковым REPL_ID разные
данные.
Наверное, ты хотел сказать наоборот, когда по разным REPL_ID одинаковые данные.
И какие ты видишь проблемы при этом в пред
On Tue, 26 Dec 2006 17:43:37 +0300, Tonal <[EMAIL PROTECTED]> wrote:
>>> Единственное возражение - слияние данных, когда по одинаковым REPL_ID
>>> разные данные.
>> Наверное, ты хотел сказать наоборот, когда по разным REPL_ID одинаковые
>> данные.
> И какие ты видишь проблемы при этом в предложе
WildSery пишет:
Единственное возражение - слияние данных, когда по одинаковым REPL_ID разные
данные.
Наверное, ты хотел сказать наоборот, когда по разным REPL_ID одинаковые данные.
И какие ты видишь проблемы при этом в предложенной мною схеме?
Которых нет в других схемах?
При обнаружении подо
> Единственное возражение - слияние данных, когда по одинаковым REPL_ID
> разные данные. Подобная ситуация может возникнуть только, если один и
> тот же объект можно редактировать в разных местах.
> Универсального решения её не существует, и гибкость решения Дмитрия -
> всего лишь способ разнести
On Tue, 26 Dec 2006 12:57:23 +0300, Tonal <[EMAIL PROTECTED]> wrote:
> Единственное возражение - слияние данных, когда по одинаковым REPL_ID разные
> данные.
Наверное, ты хотел сказать наоборот, когда по разным REPL_ID одинаковые данные.
--
Сергей Смирнов.
WildSery пишет:
Метод генерации REPL_ID-а можно выбирать любым удобным, хоть по
диапазонам, хоть GUID - по вкусу, главное чтобы в пределах системы не
пересекались.
Зависит от схемы репликации.
Где все-со-всеми и/или с возможным слиянием данных - уникальные ID
свою функцию не выполнят, тот же Дм
On Tue, 26 Dec 2006 11:34:17 +0300, Tonal <[EMAIL PROTECTED]> wrote:
> Метод генерации REPL_ID-а можно выбирать любым удобным, хоть по
> диапазонам, хоть GUID - по вкусу, главное чтобы в пределах системы не
> пересекались.
Зависит от схемы репликации.
Где все-со-всеми и/или с возможным слиянием д
WildSery пишет:
Tonal, не догнал, чем тебе помогло отдельное поле REPL_ID.
Всё равно решение задачи уникальных ID не описано.
И что мешает вместо REPL_ID использовать собственно PK ID из этой же таблицы,
формируя её по тем же принципам, что и REPL_ID?
Я, вобще-то на вопрос топика отвечал:
>>бы
> > PS. IBP v3 - это мой шатл :-)
>
> начни с личной жизни
К концу года могу, не кривя душой,
сказать - у меня с ней "дай бог каждому".
Коваленко Дмитрий.
PS. IBP v3 - это мой шатл :-)
начни с личной жизни
--
Булычев Алексей
http://www.stella-npf.ru
On Mon, 25 Dec 2006 16:49:17 +0300, Alex Cherednichenko <[EMAIL PROTECTED]>
wrote:
> Но требовать от ОТПРАВИТЕЛЯ знание номера паспорта ПОЛУЧАТЕЛЯ,
> могут только передасты из СберБанка...
Угу. Мне тут для внесения денег на свой счёт потребовали непременно почтовый
индекс своего проживания указ
On Mon, 25 Dec 2006 17:04:55 +0300, Kovalenko Dmitry <[EMAIL PROTECTED]> wrote:
> Мда, так хорошо начал... А закончил
> банальным полем BaseID в каждой таблице.
Минималист я, в основном. Не охота пудрить мозг народу своими (возможно)
глупыми идеями. Что-то ценного сказать без глубокого вникания
Привет, Варакин!
Вы пишешь 25 декабря 2006:
>> - У нас система так построена, перевод идентифицируется ПО НОМЕРУ
>> ПАСПОРТА.
ВН> ну то что какая-то там тетенька чего то ляпнула еще не значит что так оно
и есть.
ВН> а вообще я еще не встречал систем быстрого перевода которые не требовал
On Mon, 25 Dec 2006 14:46:51 +0300, Kovalenko Dmitry <[EMAIL PROTECTED]> wrote:
> Люди, напишите еще что-нибудь.
Только для тебя ;) Вставлю свою 1 копейку критики.
Andrei, разделение на диапазоны - плохая идея, не только из-за тонкостей
реализации.
Ты жёстко закладываешься на "если филиалов
"Kovalenko Dmitry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Люди, напишите еще что-нибудь.
Чти ветку приколы
KD> Люди, напишите еще что-нибудь.
KD>
KD> Когда читаешь ответы на эту тему,
KD> депрессия как-то нет так сильно давит
KD> на моск.
KD>
Дима, не все могут позволить себе такую рокошь, как написание репликации
объектов - документов. ;)
Остальные вот так и мучаются.
--
С уважением
Кочмин Алекса
Люди, напишите еще что-нибудь.
Когда читаешь ответы на эту тему,
депрессия как-то нет так сильно давит
на моск.
Коваленко Дмитрий.
>ArtGal
>FK - делаем как учили классики.
И правда ступил...
Видимо пятница не самый лучший день для начинаний любого рода.. ну
кроме пьянки. :)
> Tonal.
> Мы сделали проще - добавили в каждую реплицируемую таблицу по
> уникальному полю - REPL_ID BIGINT
А вот это мысль! Подводных камней пока не
А чем не хватает типа BIGINT?
Мы как-то решали такую проблему, как бы так обеспечить ее родимую
репликацию данных между филиалами. Сначала конечно подумали про GUID ..
Подумали дальше про диапазон значений... до сих пор вроде бы хватало
INTEGER для полей
19 значащих цифр, не уверен на счет IB
"Alex Cherednichenko" ...
> На правах прошедшей пятницы, и по поводу естественных ключей:
>
> "О тотальной идиотии в [пост]бюджетных организациях".
Теща читает этот форум ? :)
--
Хорсун Влад
AC> - У нас система так построена, перевод идентифицируется ПО НОМЕРУ
AC> ПАСПОРТА.
Неужели правда? Ужась.
--
С уважением
Кочмин Александр
Firebird Foundation associate member #257
Привет, Константин!
Вы пишешь к Юрий 23 декабря 2006:
К> Посмотри в сторону естественных ключей...
На правах прошедшей пятницы, и по поводу естественных ключей:
"О тотальной идиотии в [пост]бюджетных организациях".
Рядом с нашей конторой, был когда-то "неблагонадёжный" банк.
Хороший ли,
"Tonal" <[EMAIL PROTECTED]> сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
>
> Мы сделали проще - добавили в каждую реплицируемую таблицу по
> уникальному полю - REPL_ID BIGINT
> И триггер на инсерт, который заполняет его, если оно NULL.
Очень интересное решение.
Попробую у себя чт
Alexandr Kochmin пишет:
да, так вот если база уже есть, и без этого, то встроить это в существую
базу дюже сложно.
Мы сделали проще - добавили в каждую реплицируемую таблицу по
уникальному полю - REPL_ID BIGINT
И триггер на инсерт, который заполняет его, если оно NULL.
Соответственно, в логике
A> ALTER TABLE TAB2 ADD CONSTRAINT TAB2_TAB1
A> FOREIGN KEY (TAB1_ID, TAB1_BASE_ID)
A> REFERENCES TAB1 (ID, BASE_ID) ON DELETE тра-та-та ON UPDATE ля-ля-ля;
A>
да, так вот если база уже есть, и без этого, то встроить это в существую базу
дюже сложно.
A>> И еще, поделился бы, как ты при этом ре
"Alexandr Kochmin" <[EMAIL PROTECTED]>
сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED]
>
> ну так подскажи тогда человеку по FK
FK - делаем как учили классики.
CREATE TABLE TAB1 (
IDINTEGER NOT NULL,
BASE_IDINTEGER NOT NULL, .. );
ALTER TABLE TAB1 ADD CONSTR
A>
A> "Andrei" <[EMAIL PROTECTED]>
A> сообщил/сообщила в новостях следующее:
A> news:[EMAIL PROTECTED]
A>>
A>> если филиалов не очень много, то можно
A>> предложить схему с диапазонами ИД. На
A>
A> Не надо так делать. Гемора больше.
ну так подскажи тогда человеку по FK
И еще, поделился бы, как т
"Andrei" <[EMAIL PROTECTED]> сообщил/сообщила в
новостях следующее:
news:[EMAIL PROTECTED]
>
> если филиалов не очень много, то можно
> предложить схему с диапазонами ИД. На
Не надо так делать. Гемора больше.
PK из двух полей ID, BASE_ID прекрасно работает
четыре года на 28 базах + центральный оф
>
> Чет я туплю по жесткому в пятницу хелп... кто как решал подобную
> задачу???
>
если филиалов не очень много, то можно
предложить схему с диапазонами ИД. На
каждой базе сдвигаете значение
генератора на определенную дельту или
заводите отдельный генератор для
хранения смещения. тогда ИД
Ю> Все просто: был проект с маленьким ТЗ: 1 офис, 1 база, теперь появилась
Ю> необходимость поставить ее в нескольких филиалах.
Ю> Решил разнести филиалы добавив во все таблицы новое поле IDBASE, но
столкнулся с
Ю> проблемой FK.
Ю> Переделывая на новую версию: удаляю старые PK с одним п
Вобще-то лично мне составные FK не нравятся по некоторым соображениям. Я
все таблицы делаю по такому вот шаблону:
CREATE TABLE "_MyTable" (
"Id" "GlobalId" NOT NULL PRIMARY KEY /* "GlobalId" =
BIGINT NOT NULL */,
"LocalId" "LocalId" /* "LocalId" = INTEGER NOT NULL */,
Переделывая на новую версию: удаляю старые PK с одним полем ID,
создаю новые PK с двумя полями ID и IDBASE. Но как теперь сделать
FK?
Что-то я не понял, а какие тут проблемы с FK ?
Здравствуйте.
Все просто: был проект с маленьким ТЗ: 1 офис, 1 база, теперь появилась
необходимость поставить ее в нескольких филиалах.
Решил разнести филиалы добавив во все таблицы новое поле IDBASE, но
столкнулся с
проблемой FK.
Переделывая на новую версию: удаляю старые PK с одним п
43 matches
Mail list logo