Здравствуйте, уважаемые Мастера!

Я решаю задачу хранения довольно большого объема документов с переменным числом признаков. После довольно длительного изучения теории и тестирования было принято решение создавать эти атрибуты "напрямую", т.е. меняя метаданные, иные способы не годятся из-за невысокой скорости обработки запросов. Я уже объясняла здесь.

Дополнительно была поставлена задача найти сервер БД, по возможности - бесплатный, в роде FireBird или PostgreSQL.

Вопросы:

1. Нет ли подобного ограничения на число изменений структуры таблицы, как в FireBird (там - 255 раз "Alter table" на каждую табличку- и все, делаем Backup/Restore, чтобы счетчик сбросился)?

2. Объем "чистых" данных (в основном в Blob-ах) - в районе до сотни гигабайт (реально 20..50). Какое время резервирования/восстановления базы с таким объемом данных? (Спрашиваю, т.к. на FireBird с этим грустно...)
Существует ли возможность "Горячего" резервирования, как в FireBird?

3. Опасности, связанные с динамическим изменением базы? (В FireBird, к примеру, "Create Table ..." реально табличку не создает, до выполнения Commit. Хотя в текущей транзакции информация о табличке уже есть, но попытка записать в нее данные физически портит базу...)?

--------------
Я понимаю, что решаемая задача не является стандартным режимом для СУБД (частое изменение метаданных), но нужно.

PostgreSQL начинающий
То, что Вы описали, - криво до безобразия.

Что Вы имеете в виду?

PostgreSQL начинающий
Наймите нормального девелопера

Ну, вот меня и наняли. Вы бы лично взялись за решение подобной задачи?

PostgreSQL начинающий или сформулируйте начальную задачу (без Вашей отсебятины).

Извините, если я Вас чем-либо обидела.

Хорошо, вот другая постановка задачи: реализация модели реляционной таблицы с заранее неизвестным числом полей; некоторые поля могут быть справочниками. Поле - справочник - это ссылка на некоторую (заранее неизвестную) табличку с заранее неизвестной структурой. Этих справочников может быть сколько угодно, структура задается пользователем.
-----------------------------------------

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

XM Корюшка
1. Нет ли подобного ограничения на число изменений структуры таблицы, как в FireBird (там - 255 раз "Alter table" на каждую табличку- и все, делаем Backup/Restore, чтобы счетчик сбросился)?

макс. кол-во атрибутов 1600. Далее требуется либо Backup/Restore, либо

Видно, Вы меня неправильно поняли. Я имела в виду не допустимое количество полей, а нечто иное. Проблема не в допустимом количестве полей, а в количестве допустимых изменений таблички. В FireBird есть такая беда: существует ограничение на 255 модификаций метаданных между backup/restore. Например

То есть: работаем-работаем, потом вдруг получили сообщение об ошибке - сделаем backup и restore БД, и продолжаем работать. Неприятно.


В общем, особенность реализации. Счетчик версий структуры таблички занимает 1 байт, поэтому таких изменений может быть не более 255.

Впрочем, раз Вы про это не упомянули, то, вероятно всего, такой проблемы в PostgreSQL и нет.

XMИ есть нюанс - ALTER TABLE блокирует доступ других транзакций к изменяемой таблице.

Это просто замечательно!


XM 2. Объем "чистых" данных (в основном в Blob-ах) - в районе до сотни гигабайт (реально 20..50). Какое время резервирования/восстановления базы с таким объемом данных? (Спрашиваю, т.к. на FireBird с этим грустно...)
Существует ли возможность "Горячего" резервирования, как в FireBird?
Как я понял, это связано с вопросом 1. В принципе, есть on-line backup, но не проще ли вынести BLOB'ы в отдельную таблицу (если для FireBird BLOB используется тип PostgreSQL BYTEA) или использовать PostgreSQL Large Objects (lo_*)?
[/quot]

Я не совсем поняла насчет отдельной таблички. Меня интересует время восстановления всей базы из резервной копии. При указанных объемах до сотни гигабайт.


3. Опасности, связанные с динамическим изменением базы? (В FireBird, к примеру, "Create Table ..." реально табличку не создает, до выполнения Commit. Хотя в текущей транзакции информация о табличке уже есть, но попытка записать в нее данные физически портит базу...)?

BEGIN; CREATE TABLE; INSERT; COMMIT; работает корректно
[/quot]
Это радет больше всего :).


---------------
Спасибо, Вы мне очень помогли в выборе.
---------------
---------------
---------------
2 PostgreSQL начинающий - спасибо за предложенную помощь, пожалуй, не нужно.
----------------------------------------------
Вопрос: компоненты доступа к PostgreSQL из Delphi, кроме Zeos и BDE + ОDBC?

vfabr
хотите сказать что
был документ у которого было 5 признаков
потом провели какието манипуляции и у него стало 6 признаков
потом сделали еще чтото и у него стало 4 признака?

Совершенно верно! Только не документ, а набор документов. По аналогии с таблицей: было 5 полей, потом 6, потом 4. (Реально - в районе полусотни) . Поля разных типов. Плюс некоторые поля - ссылки на справочники. Справочники тоже разной структуры. Структуру пользователь создает.
vfabr
вобще начинающий помоему прав. переменное число столбцов это неправильно.


Еще как неправильно! Если бы не деньги, которые мне платят, давно бы бросила.
Заказчик уже получил систему, работающую подобным образом, и он желает ее использовать и далее, но более масштабно. "Старый" вариант реализации не меняет метаданные, а создает "динамические" справочники с помощью массы Join - ов. Однако при наличии большого числа подобных соединений поиск, группировка и сортировка по этим признакам вызывают, мягко говоря, некоторую задумчивость системы. Есть еще один вариант реализации, более быстрый, но менее гибкий.

PostgreSQL начинающий Вы задали вопрос, я на него ответил.

Неправда, Вы не ответили ни на один из трех заданных мною вопросов, а зацепились за описание задачи предметной области.

PostgreSQL начинающий Если бы я принял участие в каком-то проекте, то только при условии, что это open source проект.
Вас никто не просил принимать участие в проекте (я даже Вашего резюме не видела).
--------
Все же я не думаю, что совершила ошибку, рассказав об основной задаче своей предметной области, хотя сразу предполагала массу отвлекающих от темы вопросов.
Было бы как минимум смешно врать о том, для чего мне нужно часто менять метаданные (>: "...создаю свой дизайнер СУБД" ), если я задаю такие примитивные вопросы.
--------
Проект не Open-Source; и даже если бы я и выложила все исходники на всеобщее обозрение: это проект - COM/DCOM - примочка к существующей коммерческой (никак не Open-Source) системе, и самосоятельная ценность его близка к нулю.
--------
Как я уже сказала, у меня есть пара "мягких" реализаций (не меняющих структуру метаданных) поставленной задачи, однако повышенный интерес клиентов к данной системе вызвал более чем десятикратную нагрузку на систему, и нагрузка вырастет еще. Время реакции системы стало слишком велико. Поэтому и выбран тот вариант, о котором рассказано.
--------
Не думаю, чтобы Вы, уважаемый PostgreSQL начинающий, смогли рассказать мне в плане моей задачи что-либо новое. По крайней мере, я ни разу Вас об этом не просила.
--------
Все, что мне осталось выяснить - это мой вопрос №2 (по поводу времени восстановления из Backup), но, думаю, что это мне станет известно сегодня к вечеру (или завтра), когда прогоню несколько тестов.
--------

PostgreSQL начинающий
Судя по сказанному Вами, в наличии как минимум три принципиальные ошибки:
1. Неправильный выбор СУБД.
2. Неправильный выбор способа хранения документов.
3. Неправильная структура данных для "документов с переменным числом признаков".

Рассказать, в чем главная ошибка заказчика или самостоятельно догадаетесь?
Рассказать, на какие грабли Вы наступите в первую очередь?


Я дважды называла вопросы, которые мне были интересны. Спасибо за заботу, уважаемый PostgreSQL начинающий, но повторюсь еще раз: меня волновали отнюдь не вопросы методологического или организационно-правового обеспечения, и даже Ваш богатый опыт применения средств малой сельской механизации.

Спасибо, было очень интересно. PostgreSQL начинающий, Вы просто душка. Жаль, что Вы не можете сконцентроваться в рамках заданного вопроса.

----
Да, по поводу средств доступа из Delphi: на данный момент я использую Zeos, но тестирую (в т.ч. и на вопрос покупки) PostgresDAC v.2.2.1 (от MicroOLAP).
----
Еще раз всем спасибо.

Однако, уместна ли тема обсуждения в данном форуме? Ну, думаю, ладно, будем это рассматривать как безвредный воскресный флейм. Заодно и рейтинг форума поднимем. :) ... раз Вы так настаиваете :). Мне даже лестно такое незаслуженное внимание.

Предлагаю в процессе обсуждения опускаться до пола собеседника, размера головного мозга, его национальности, возраста и т.п., хорошо?

Расскажите, пожалуйста, о своем видении мира в плане затронутых вопросов. Очень Вас прошу.

Я готова уточнить все вопросы, которые Вас интересуют.

И так, я слушаю Вас.

Ой, какой-то я ерундой занялась. Извините, PostgreSQL начинающий, я была неправа. Нужно чаще отдыхать.

Всем - спасибо и всего хорошего.

PostgreSQL начинающий

По существу: Вы предлагаете реализацию части функций СУБД в приложении. Сильно сомневаюсь, что Ваше приложение будет выполнять функции СУБД лучше, чем СУБД. Вы получите плохо сопровождаемый код, который потребует хорошего документирования и поимеете кучу проблем при возможном переходе на другую платформу или при изменении состава разработчиков.

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

Т. е. если Вы безусловно уверены в том, что ничто, кроме того, что Вы реализуете, Вам никогда не понадобится, - тогда да, Ваша реализация оправданна. Только хм... одноразовое какое-то приложение получается, Вы не находите?

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

Что? Опять?

Я спрашивала что-то, из перечисленного Вами?

Еще раз, мой вопросы, специально для Вас:

1. Нет ли в PostgreSQL ограничений на допустимое число модификаций метаданных таблички между backup/restore, как в InterBase (не более 255)?
Варианты ответа:
- да, есть, вот такие:...
- нет (, однако...).
2. Не можете ли дать оценку времени восстановления базы объемом до сотни гигабайт из резервной копии на каком-либо типовом оборудовании.
Ответить можно так: ("...да, для моей конфигурации P-IV-... е.т.с...., база объемом 35 ГБ (На диске занимает 60 ГБ)... ") :
- Backup (в таких-то условиях) занимает 30-40 минут;
- Restore (в таких-то условиях) занимает 2 часа 40 минут;

3. Хотелось бы узнать, существуют ли какие-нибудь сложности, и рекомендации, связанные с динамическим изменением структуры базы? (В FireBird, к примеру, "Create Table ..." реально табличку не создает, до выполнения Commit. Хотя в текущей транзакции информация о табличке уже есть, но попытка записать в нее данные физически портит базу...)?
Можно не отвечать - уже ответили. Спасибо Вам огромное, уважаемый ХМ . Вы пока единственный, кто меня услышал.

Да, вот еще всплыл вопрос:

4. В FireBird есть такое понятие: "невосстановимый Backup". Это - возникновение такой ситуации, когда сохраненные данные невозможно восстановить вследствие имеющихся в базе ограничений. Например, я изменяю описание типа данных столбца таблицы: добавляю констреинт "Not Null". В FireBird такое допустимо, даже если имеются записи с данными в этом поле, имеющими значение "Null". Так вот, Backup таких данных проходит без проблем, а при попытки восстановления включается констреинт - и - всё, данные не восстанавливаются.
И так, вопрос: есть ли такое понятие в PostgreSQL, как "невосстановимый Backup", или на исправной базе + исправном оборудовании восстановление должно проходить без проблем?
----------------------------
PS: Я не тешу себя надеждой услышать что-либо вразумительного от PostgreSQL начинающий. (Ну нет здесь вопроса типа "посоветуйте выбрать архитектуру" и т.п., не-е-ту.)
Мне представляется, что вопросы совершенно примитивны. Ответить на них может всякий, кто имеет опыт работы с этой СУБД.
Перечисленные вопросы - головная боль для меня при работе с FireBird. Поиск в документации пока ничего не дал. Опыт работы конкретно с этой СУБД у меня, как видите, минимальный.

Помогите, если кто знает. Обещаю потом и про архитектуру поговорить, и про тесты на быстродействие, и про поэзию Марины Цветаевой...

PostgreSQL начинающий1. Что мешает эмулировать: открыть соединение, сделать алтер тейбл, закрыть соединение?
2. Что мешает создать тестовую базу данных?
4. Что мешает посмотреть реальный дамп на предмет очередности создания/восстановления объектов?
...

И чего так растраиваться, не понимаю. Если не знаете, то вовсе не обязательно отвечать "хоть что-то". Не проще промолчать?
-----

Два дня назад мешало отсутствие опыта работы с этой СУБД. Сейчас почти не мешает. Однако, время потеряно.


Специалисты, к счастью, нашлись, но не здесь.

Все вопросы решены.

4321По поводу 1. ответ о конечности числа атрибутов имеет к нему отношение. Ибо все дропнутые столбцы "на самом деле" остаются в структуре и занимают свое место в числе атрибутов таблицы (в системных таблицах имеют имя наподобие ...dropped... и неопределенный вид, причем весьма "восстановимы" путем прямого ручного воздействия на системные таблицы запросами UPDATE ... SET имя = ..., тип = ...)). Избавиться от дропнутых столбцов можно только пересоздав таблицу. Например при подъеме дампа.


Спасибо, учту.

4321
по поводу 3. Всякое баловство с подменой таблицы вновь созданной или же с заменой/пересозданием ключей и индексов чревато необходимостью подъема наново всех процедур, в которых задействованы подменяемые таблицы или могли быть явно/неявно задействованы ключи и (иногда) даже индексы. Ибо откомпиленная процедура знает оид релейшена, но не его имя. Так я как-то наткнулся на ошибку "релейшен (скажем~) 4321 отсутствует" после сноса и создания обыкновенного индекса. Причем эта ошибка повторялась даже после перезапуска всех CREATE OR REPLACE ... до тех пор, пока я не вышел из сеанса и не вошёл по новой (видимо ф-я сидела в кэше).

Этот вопрос был решен (по крайней мере, в InterBase) так: для таких динамических структур строится дерево зависимостей, при обходе которого, генерируется модифицирующий скрипт. Т.е., к примеру, сносим все зависимые процедуры/триггеры, меняем структуру таблички, воссоздаем процедуры/триггеры и т.д. В общем, все не так уж и сложно. Ну, с особенностями Postgre, естественно, еще придется разобраться.

Спасибо.

mwolfПофлеймим? :-)...
Производительность - никакая. ...

Да, в описанной Вами схеме зависимость времени выборки от числа дополнительных атрибутов - линейная.

mwolf... я тоже всерьёз раздумывал об ALTER TABLE.

Есть еще варианты, более быстрые и не изменяющие метаданные базы, но возникла необходимость в атрибутах - справочниках, и время обработки подобной "над-мета"-структуры тоже стало медленновато.