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