Привет.
Да нет. Это не версионность. Знаний у
человека мало. :-(((
Тут много раз говорили, что и Оракула
тупыми мозгами завалить можно, а MS SQL и
умными не сложно. :-))
Дмитрий
http://www.sql.ru/forum/actualthread.aspx?tid=379863
:-)
Ded ...
Horsun Vlad wrote:
Посчитаем среднедневной оборот чего-либо за произвольный период с
приведением к произвольной валюте с учётом колебаний курса в этом периоде ?
Влад, а вот например книгами Ковязина и Елены очень неудобно
забивать гвозди.
От переплёта зависит. И от
Ded [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
PS А я сегодня ещё успел классный регулятор купить, Legend Supreme LX
ACD. Утверждается, что на 50 метрах дышится так же легко, как на
поверхности. Спытаем :)
А посмотреть характеристику сопротивления вдоху в зависимости от
Horsun Vlad wrote:
Если ты мне докажешь, что дата окончания периода действия состояния
сущности не есть хранимый агрегат (даже два), то тогда я может быть изменю
своё мнение
Дата окончания периода действия равна дате начала следующего.
Хранение её отдельно есть денормализация
Oleg LOA wrote:
А посмотреть характеристику сопротивления вдоху в зависимости от глубины до
испытаний? :-)
Теоретически - луччий на сегодня образец, сверхсбалансированная
первая ступень, сбалансированная вторая с заслонкой Вентури. Проверим :)
--
Regards. Ded.
On Fri, 20 Oct 2006 13:28:37 +0400, Ded [EMAIL PROTECTED] wrote:
Дата окончания периода действия равна дате начала следующего.
Хранение её отдельно есть денормализация дублированием. Что не всегда
есть неправильно. Но обеспечить неперекрываемость интервалов в
конкуретной среде изменений
Привет.
Dmitri Kuzmenko [EMAIL PROTECTED] сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
могу предложить свои мысли (буде статья, включим туда), по поводу
курсов валют.
при организации курсов валют есть 2 классические ошибки, исходящие
из прямого решения задачи - хранения
Dmitri Kuzmenko ...
Hello, Глеб!
Мадорский Г.В. wrote:
Имхо, пусть уж лучше где-то данные дублируются.
От дополнительных табличек с историей значения каждого реквизита я
отказался. Уж больно мудреные SQL получаются. Сейчас храню версии записи
с диапазоном дат, указывающим период ее
Любые временнЫе данные, которые читаются чаще, чем редактируются,
и могут быть разреженными (т.е. значения могут быть одинаковыми в течение
нескольких минимальных периодов измерения) удобнее всего хранить с двумя
датами - начала и окончания времени действия данного значения. Это
добавляет
Boulitchev Aleksey ...
Любые временнЫе данные, которые читаются чаще, чем редактируются,
и могут быть разреженными (т.е. значения могут быть одинаковыми в течение
нескольких минимальных периодов измерения) удобнее всего хранить с двумя
датами - начала и окончания времени действия
Любые временнЫе данные, которые читаются чаще, чем редактируются,
и могут быть разреженными (т.е. значения могут быть одинаковыми в течение
нескольких минимальных периодов измерения) удобнее всего хранить с двумя
датами - начала и окончания времени действия данного значения. Это
добавляет
Sergey Kovalev wrote:
А есть еще организации, которые работаю в субботу и воскресенье. Там
хочешь - не хочешь, а будешь на пятницу смотреть.
А что, сайт РБК и прочая на выходные закрывается? В организациях,
достойных так именоваться, курсы разных валют и типов ставит бот,
заглядывая
Horsun Vlad wrote:
Я не понял - это согласие или похер моего мнения ? :)
В моей схеме последний действительный документ на указанную дату
выбирается простым селектом с BETWEEN - никаких подзапросов, группировок
и т.п.
А когда таковых больше одного - получаем multiple rows in
Привет.
Ded [EMAIL PROTECTED] сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
Horsun Vlad wrote:
Я не понял - это согласие или похер моего мнения ? :)
В моей схеме последний действительный документ на указанную дату
выбирается простым селектом с BETWEEN - никаких
Ded ...
Horsun Vlad wrote:
Я не понял - это согласие или похер моего мнения ? :)
В моей схеме последний действительный документ на указанную дату
выбирается простым селектом с BETWEEN - никаких подзапросов, группировок
и т.п.
А когда таковых больше одного - получаем
Мадорский Г.В. wrote:
А когда таковых больше одного - получаем multiple rows in singleton
select?
А как оно там больше одного получится при условии, что диапазоны дат для
каждой версии записи не пересекаются?
Чуть ниже.
И чем битвин лучше фирста по индексу?
Select D.Num,
Horsun Vlad wrote:
И чем битвин лучше фирста по индексу?
Выбери мне все валюты на заданную дату :) Или все док-ты по состоянию
на заданную дату
А на фига? Какой за этим осмысленный функционал стоит?
--
Regards. Ded.
Ded ...
Horsun Vlad wrote:
И чем битвин лучше фирста по индексу?
Выбери мне все валюты на заданную дату :) Или все док-ты по состоянию
на заданную дату
А на фига? Какой за этим осмысленный функционал стоит?
Я же говорю - разные у нас задачи ;)
Есть некий
А когда таковых больше одного - получаем multiple rows in singleton
select?
А как оно там больше одного получится при условии, что диапазоны дат для
каждой версии записи не пересекаются?
Чуть ниже.
И чем битвин лучше фирста по индексу?
Select D.Num, C.Address
from Doc D
Marcoci Dorin ...
Не знаю, я просто блокирую все версии одной записи. Мне как бы большего
не требуется.
Просто не получается. Если найдется какой-то хмырь юзер каторый будет делать
апдэйт неблокируя то этой теории конец.
Это ты о какой СУБД говоришь ?
Нету гарантии что дапазон
Marcoci Dorin [EMAIL PROTECTED]
сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED]
Не знаю, я просто блокирую все версии одной записи. Мне как бы большего
не требуется.
Просто не получается. Если найдется какой-то хмырь юзер каторый будет
делать апдэйт неблокируя то этой
Я не понял - это согласие или похер моего мнения ? :)
задачи разные:)
В моей схеме последний действительный документ на указанную дату
выбирается простым селектом с BETWEEN - никаких подзапросов, группировок
пробовали диапазонами, но сильно тяжело получилось. это применительно к
Marcoci Dorin [EMAIL PROTECTED]
сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED]
У меня все хмыри-юзеры исключительно через мою программу к базе ходют...
Ну ... так еще вариант имеет право на жизнь.
А когда доступ к базе из разных програм, веб приложениях итп, а еще даем
Гм. Версионность подразумевает наличие не более одной (валидной) версии
сущности (видимой конкретному наблюдателю) на каждый момент времени. Так
что я
даже затрудняюсь назвать ту сущность, о которой говорится выше. imho, тут
явно другая задача :)
действительный, конечно, один, просто
Marcoci Dorin пишет:
Угу, а теперь представляем себе, что этот юзер может написать delete from
rdb$pages и понимаем, что программу вааще писать бессмысленно. :)
А что права уже отменяли?
На rdb$pages их и не вводили. :)
Horsun Vlad wrote:
Есть некий аналитический учёт, т.е. он 'мельче' (подробнее) бухгалтерского.
Бух. проводки учитываются в номинале и грн. эквиваленте заданной валюты. Но
аналитика более подробна, посему нет возможности пользоваться грн. эквивалентом
из бух. проводки. Либо нам нужен не
Мадорский Г.В. wrote:
Ну а все-таки поведай, как ты поступаешь, когда меняется дата
актуальности какой-то версии записи в справочнике? Шерстишь все
документы и подменяешь где надо IdClient_Generation?
Ну да. Скажи, у тебя например поставщики часто названия меняют или
переезжают с места
On Thu, 19 Oct 2006 16:34:06 +0400, Ded [EMAIL PROTECTED] wrote:
Дык я и храню курсы а) в документе на момент регистрации б) в каждой
записи об операции, связанной с документом на момент операции. Это кроме
бухгалтерских проводок, бухгалтерия бухгалтерией, но я регистрирую
потоки
WildSery wrote:
Не понял, курсы всех валют хранишь сразу?
Т.е. если у меня рублёвый документ, с примесью долларов, а бух захотел
посмотреть всё это в евро - то данных из документов достаточно для этого?
А если в юанях? Реальный интерес представляют данные в валюте
документов и во
WildSery wrote:
Т.е. если у меня рублёвый документ, с примесью долларов
Кстати, покажи пожалуйста настоящий документ с примесью. Не расписку
что Вася должен Пете, а документ. Я не видал ещё. Скажем счёт в одной
валюте и десяток оплат по нему в разных - это скока угодна. Но оплата -
не
On Thu, 19 Oct 2006 17:34:38 +0400, Ded [EMAIL PROTECTED] wrote:
Кстати, покажи пожалуйста настоящий документ с примесью. Не расписку
что Вася должен Пете, а документ. Я не видал ещё. Скажем счёт в одной
валюте и десяток оплат по нему в разных - это скока угодна. Но оплата -
не составная
WildSery wrote:
Подразумевался документ с номенклатурами в разной валюте учёта, т.е. курс
отличный от 1.0 для некоторых позиций.
Что-то тут с консерваторией. Но углубляться не могу, горю как швед
под Полтавой, с понедельника в отпуск, а ещё нужно успеть подлизать баги
и внедрить новую
Ded ...
WildSery wrote:
Подразумевался документ с номенклатурами в разной валюте учёта, т.е. курс
отличный от 1.0 для некоторых позиций.
Что-то тут с консерваторией.
Это просто другая консерватория :-P
Но углубляться не могу, горю как швед под Полтавой, с понедельника в
Угу, а теперь представляем себе, что этот юзер может написать delete from
rdb$pages и понимаем, что программу вааще писать бессмысленно. :)
да Серега уже час развлекается удаляя из-под PUBLIC всякие rdb$ таблички
grant select on rdb$* to SYSDBA работает только до b/r
на четвертом кандидате
Horsun Vlad wrote:
Посчитаем среднедневной оборот чего-либо за произвольный период с
приведением к произвольной валюте с учётом колебаний курса в этом периоде ?
Влад, а вот например книгами Ковязина и Елены очень неудобно
забивать гвозди. У нас тоже есть и учредители и аналитики, и
Alexander Goldun wrote:
Валюта таможенной стоимости может отличаться от
валюты инвойса.
Я бы сказал, не может, а должна. Только таможенные сборы платятся не
по инвойсу и не по конасаменту и не по CMR, а по Государственной
Таможенной Декларации. Которая есть самостоятельный документ,
Marcoci Dorin [EMAIL PROTECTED]
сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED]
Привет знатокам,
Настало время встраивать историю записей в базе.
Щас работаем по принципу как это сделано в 1С 7.7 (история отдельных
атрибутов (полей)), все работает хорошо. Но появились более
Marcoci Dorin wrote:
Речь идет о переодических реквизитах или об аудите действий пользователей?
Или обо всем в одном флаконе?
Мне надо щас разрабатывать механизм которы позволял получать версию записи
на определенном этапе (во времени, или например по стадии продвижения записи
(например
Привет, Marcoci!
Вы пишешь 18 октября 2006:
MD Две таблицы:
[Sorry, skipped]
MD Что скажете?
Достаточно одной таблЭтки. (С)
Две - это уже много.
--
With best regards, Alex Cherednichenko.
Привет, Marcoci!
Вы пишешь 18 октября 2006:
Достаточно одной таблЭтки. (С)
Две - это уже много.
MD :) А тянуть последние версии записей если версий дохера не будет проблема?
Нет.
Но запросы несколько усложняются.
MD В вышеупомянутой статье, насчет это, автор пишет:
Не читал.
--
With
Речь идет о переодических реквизитах или об аудите действий
пользователей? Или обо всем в одном флаконе?
Кажется надо все в одном флаконе.
Я у себя разделил в конце концов. Хоть и есть в обеих случаях что-то общее,
но суть разная. И ежели в одной части чего-то менять/дописывать надо, то
Marcoci Dorin wrote:
:) А тянуть последние версии записей если версий дохера не будет проблема?
В вышеупомянутой статье, насчет это, автор пишет:
А ты сначала задай себе вопрос - а куда тянуть. Периодические
реквизиты характерны тем, что их выбирает не Вася Пупкин, глядючи на
длинный
Marcoci Dorin wrote:
1. A(ID, CURRENT_VERSION_ID)
2. B (ID, FDATE, ADDED_BY, NAME, ADRESS )
Для текущих версий можно делать вюху типа:
select A.ID, B.NAME, B.ADRESS
from A join B on (A.CURRENT_VERSION_ID = B.ID)
Заодно и история всех записех сохранается, + дополнительные поля для
Hello, Ded!
Ded wrote:
Скажу, что понятия текущая версия - самообман. Большинство
официальных документов формируется так или иначе задним числом, пусть и
с небольшой задержкой. А для внутренних, генерируемых автоматом или
полуавтоматом периодические реквизиты не нужны. То есть, польза ID
Добрый день, Dmitri!
Вы писали от Wed, 18 Oct 2006 16:32:08 +0400:
DK ну забабахайте кто-нибудь статью про периодические реквизиты.
DK я ж не могу, не мое это. вот про оптимизатор на след. неделе
DK выложу, подарок, так сказать.
Тут вроде речь шла о полном логе изменений данных а не о
Hello, Глеб!
Мадорский Г.В. wrote:
Имхо, пусть уж лучше где-то данные дублируются.
От дополнительных табличек с историей значения каждого реквизита я
отказался. Уж больно мудреные SQL получаются. Сейчас храню версии записи
с диапазоном дат, указывающим период ее актуальности. Соответственно
Dmitri Kuzmenko wrote:
Поэтому для текущих курсов валют нужно организовать таблицу вида
currency_code+value
без даты, и заполнять значения КАЖДЫЙ ДЕНЬ при смене курса
какой-нибудь процедурой.
Теория это. А действительность такова.
1. В понедельник по пятнице серьёзные люди и не работают.
On Wed, 18 Oct 2006 19:22:24 +0400, Dmitri Kuzmenko [EMAIL PROTECTED] wrote:
select value, max(date)
from currency
where currency_code = :param
group by value
create descending index cur_idx on currency (date, currency_code);
for select value, date
from currency
where date = :param1
Hello, Ded!
You wrote on Wed, 18 Oct 2006 17:41:07 +0400:
D юзеру может ударить в голову самая неожиданная моча, если
D будет на то воля аллаха.
И если не будет воли аллаха - тоже. И систематически ударяет. Блин! (это я
о своем) : У нас вот бухи в 1С повадились вместо документа-сторно
Доброго времени суток, !
Ошибка 1.
Для оперативного пересчета курса валют на текущий день
строится запрос вида
select value, max(date)
from currency
where currency_code = :param
group by value
select first 1 value from currency
where currency_id = :id and currency_date = :dt
order by
51 matches
Mail list logo
