» InterBase и FireBird: вопросы по работе и их решение

NikRON
Иногда лучше жевать молчать.

NikRON
имхо, если уж мигрировать на FB 2.5, то лучше воссоздать скелет базы из скрипта с метаданными, а затем перелить данные с нужной кодировкой IBPump'om (кстати, у меня он отказывался работать, пока из всего зоопарка серверов я не оставил лишь один да и то в качестве службы. Проверьте, плз, прав ли я в своих догадках?)

eddoc

Проще не IBPump (который кстати уже стар) а fbclone
fbclone - сам создаст структуру и перенесет данные

noisy

Цитата:

Проще не IBPump (который кстати уже стар)

Поскольку это утилита командной строки и у него нет ГУЕв, то она больше подходит для суровых сибирских лесорубов любителей стучать пальцами по клаве в cmd-окошке

Так что, все относительно ...

Добавлено: а вот кстати и [more= хелп]Syntaxe : fbclone.exe [-h] [-v] [-po] [-e] [-d <file>] [-rd <file>] [-ps <page size>] -s <database> [-su <user>] [-sp <password>] [-sl <library>] -t <database> [-tu <user>] [-tp <password>] [-tl <library>] [-tc <charset>] [-rc <charset>] [-wc <charset>] [-xt <list>] [-u <user>] [-p <password>] [-l <library>] [-f] [-ci <number>]

Arguments pris en charge par l'application :
-h, -help    [optional]
    Show this help message

-v, -verbose    [optional]
    Show details

-po, -pump-only    [optional]
    Only pump data from source database into target database (source database and target database must share the same metadata structure)

-e, -empty-tables    [optional]
    Empty tables before data pump

-d, -dump    [optional]
    Dump SQL script into file

-rd, -repair-dump    [optional]
    Trace errors and SQL into a repair.sql file

-ps, -page-size    [optional]
    Overrides target database page size

-s, -source
    Source database connection string

-su, -source-user    [optional]
    User name used to connect source database

-sp, -source-password    [optional]
    Password used to connect source database

-sl, -source-library    [optional]
    Client Library used to connect source database

-t, -target
    Target database connection string

-tu, -target-user    [optional]
    User name used to connect target database

-tp, -target-password    [optional]
    Password used to connect target dat base

-tl, -target-library    [optional]
    Client Library used to connect target database

-tc, -target-charset    [optional]
    Target database default character set (default: source charset)

-rc, -read-charset    [optional]
    Character set to read from source database (default: source charset)

-wc, -write-charset    [optional]
    Character set to write into target database (default: source charset)

-xt, -exclude-table    [optional]
    Comma separated list of tables to exclude from data pump

-u, -user    [optional]
    User name used to connect both source and target databases

-p, -password    [optional]
    Password used to connect both source and target databases

-l, -library    [optional]
    Client Library used to connect both source and target databases

-f, -failsafe    [optional]
    Commit transaction every record (same as using -ci 1)

-ci, -commit-interval    [optional]
    Commit transaction every <number> record[/more] к нему

Вопрос, может не совсем по firebird..

есть несколько таблиц вида
table1 с полями value1_1, value1_2, .. value1_N, date_start1
table2 с полями value2_1, value2_2, .. value2_N, date_start2
...
и так далее. фактически это какие-то справочники необходимые для расчётов, где значения в поле date_start содержат информацию о том, что с этой даты вступают в силу значения указанные в этой строке.

какой алгоритм посоветуете, для того чтобы данные этих справочников объединить в одну таблицу, в которой будут перечислены все поля из этих таблиц (кроме дат) и так же дата, с тем же смыслом что и в старых таблицах.
Например есть
таблица 1
значение1 дата1
10 01.01.2012
15 01.05.2012

таблица 2
значение2 дата2
1 01.01.2012
3 01.07.2012

в результате нужно получить такие данные
дата значение1 значение2
01.01.2012 10 1
01.05.2012 15 1
01.07.2012 15 3

druff
алгоритм примерно такой
1. вставить всё из таблицы 1 в новую таблицу
добавится
data, value1, null
2. проапдейтить новую таблицу значениями из 2й таблицы (по дате, те которые найдутся)
станет
data, value1, value2
3. вставить всё, что не нашлось из таблицы 2 в новую таблицу
добавится
data, null, value2

ant0ni02004
да, но я в результате получу

data v1 v2
01.01.2012 10 1
01.05.2012 15 null
01.07.2012 null 3

и для того чтобы узнать данные в последней строке нужно будет откатываться по временной шкале назад на неопределённое количество строк

Да, и я наверное неправильно выразился.. Под новой таблицей я не имел ввиду физическую табличку (хотя может и она подойдет). Скорее таблица как результат работы запроса или ХП.

druff

select value1, value2 from table1
union
select value1, value2 from table2
union
select value1, value2 from table3

А чтобы избавиться от Null, тут ХП-шкой надо пробегать по результатам этого селекта и в локальных переменных "накапливать" значения на определенную дату.
Дата сменилась - делаем SUSPEND в процедуре.

Но торvознуто будет на больших данных.
Лучше изначально сделать одну таблицу и заполнять ее тригерами при изменении исходных table1, table2...

очень быстрое решение, могу и ошибиться, проверить не на чем

Код:
select
tabledt.dt,
(select value1 from table1 where data1 = tabledt.dt),
(select value2 from table2 where data2 = tabledt.dt)
from (select data1 as dt from table1 union select data2 as dt from table 2) as tabledt

AlexPetrovich
честно, не понял как воспользоваться этим запросом с union'ами

noisy
когда поле с данными в этих таблицах только одно, то хорошо. А если полей с десяток?

druff

Цитата:

нужно будет откатываться по временной шкале назад

я не совсем неправильно понял чего хотелось
это лучше хранимой процедурой делать с итерацией по дням (365 раз на год - пустяки)
а еще лучше сводной таблицей. места на винте сейчас много и дешево

ant0ni02004
таблиц для соединения просто очень много.

для каждого лицевого счёта есть с десяток таблиц, каждая со своей историей. Для того чтобы сделать расчёт этому лиц. счёту, нужно разбить месяц на отрезки, в которых гарантировано не происходило изменений данных лиц. счёта (которые хранятся в разных таблицах).

т.е. получить эту самую сводную табличку с информацией
с 1 января площадь квартиры была 20м2, количество проживающих 2чел, показания счётчика 17м3
с 15 января всё то же самое, но количество проживающих - 3.

и т.д. Только параметров и таблиц гораздо больше.

druff
Может проще структуру БД пересмотреть ?

noisy
хранить всё в одной таблице? Если серьёзно, то я стараюсь упростить схему. Но правила нормализации никто не отменял ) Хранить свойства совершенно разных объектов (справочник тарифов, справочник абонентов, список услуг у этих абонентов и т.д. ) в одной таблице?

Цитата:

table1 с полями value1_1, value1_2, .. value1_N, date_start1
table2 с полями value2_1, value2_2, .. value2_N, date_start2

Это справочник?
сложно судить о БД по двум строкам.
но эти строки явно показывают что было выбрано удобство отображения данных на клиенте, а не обработки данных

ведь с таблице вида
дата - тип - значение
проще работать на стороне сервера чем с таблицей
дата - значение1 - значение2 - ... - значениен

Код: execute block
returns (date_start date, value1 integer, value2 integer)
as
begin
for select distinct date_start1
from table1
union
select distinct date_start2
from table2
order by 1
into :date_start
do begin
select value1_1
from table1
where date_start1=:date_start
into :value1;

select value2_1
from table2
where date_start2=:date_start
into :value2;

suspend;
end
end

exteris
в принципе да, жизненно, у меня сейчас похожим образом происходит, только в цикле нужно такие запрос поставить (дата, которая есть в первой таблице, может отсутствовать во второй и наоборот)


Код: do begin
select first 1 value1_1
from table1
where date_start1 <= ate_start
order by date_start1 desc
into :value1;

select first 1 value2_1
from table2
where date_start2 <= ate_start
order by date_start2 desc
into :value2;

suspend;
end

druff
"пусть, например, table1 будет справочником тарифов, с полями дата_изменения,"

Очень советую переделать "дата_изменения" в справочниках на "период действия". типа так:

дата_начала_действия дата_конца действия значения
01.01.2012 05.05.2012 500
06.05.2012 30.09.2012 550
01.10.2012 01.01.2100 700 ---- Это текущий действующий

Тогда не надо будет "чтобы узнать данные в последней строке нужно будет откатываться по временной шкале назад на неопределённое количество строк".

Любой действующий параметр можно будет получить через WHERE _date between DateBegin and DateEnd.

А если есть только "дата_введения_в_действие", то без перебора истории в цикле никак.

AlexPetrovich
для итоговой таблицы с интервалами я так и хочу сделать. В справочниках будет сложнее. Пользователь ничего не знает о дате окончания и её нужно формировать автоматически, значит лишняя нагрузка на сервер..

Добавлено:
AlexPetrovich
да, и по какому алгоритму объединять справочники, если хранить дату начала и дату конца?

druff
А пользователю и не нужно знать дату окончания.
он сказал новый тариф с такого-то числа.
а дату окончания предыдущего тарифа легко заменить на (дата начала нового - 1 день)
и у каждого тарифа есть дата окончания, и у нового, но она заведомо большая, например 2200 год, но ни в коем разе не null!
а нагрузка на сервер сводится к одному апдэйте.

Есть ли какие средства мониторинга БД на случай нарушения целостности. Т.е. возникли какие проблемы у сервера при доступе к БД и немедленно сообщить об этом администратору. Или периодически запускать проверку целостности БД и при ошибках так же немедленно сообщать администратору. Логи смотоеть не всегда есть возможность.

AlexCoRu
FBDataGuard

OXDBA, по-дешевле ничего?

noisy
Дата окончания избыточна и не нужна
Типичная ошибка новичков в версионных справочниках
Дата - Значение - все что нужно

YuriyRR
Ага, счаз.

Приведи пример запроса определения начисленной суммы за услугу, если тариф менялся несколько раз за период ?
А с датой окончания все просто - where "дата_оказания услуги" between "тариф_дата_начало" and "тариф_дата_конец".

YuriyRR

Так научите "желторотиков", примеры в студию

AlexCoRu

Цитата:

по-дешевле ничего?

Я больше скажу, не то что подешевле, а вообще альтернативы не нашел.

AlexCoRu
exteris
Да, с альтернативой очень плохо.
По ценам ничего не скажу, я был бета-тестером, поэтому за софт не платил.
AlexCoRu глянь личку.

AlexCoRu

Цитата:

по-дешевле ничего?

По дешевле - еженочный бэкап/рестор с проверкой на ошибки самопальными скриптами.

В принципе при нормальном железе вероятность "битья" базы ооочень низкая.

Нужен еще больший запас надежности - репликация( через определенный интервал вреени или сразу после изенения данных).

Я тоже думаю, что БД довольно-таки надёжная. Был один случай развалилась локальная и то электричество прыгнуло, но легко восстановили. А БД переместили на сервер с бесперебойником.
Вообще-то, мне задали вопрос: как проверить целостность бэкапа, а я как-то и не задавался таким вопросом никогда - делается и делается, если создался - значит хороший. И вот тут-то мне и подумалось, а если база битая, то и бэкапиться будет битая. Значит перед бэкапом нужна проврка целостности.