Представлен (http://comments.gmane.org/gmane.comp.db.postgresql.announce/...) релиз инструмента pg_extractor 1.0.0 (https://github.com/omniti-labs/pg_extractor), предназначенного для фильтрации и извлечения данных из файлов с дампами баз PostgreSQL. Код программы написан на языке Perl и распространяется под свободной BSD-подобной лицензией PostgreSQL.
Основные особенности:
- Сохранение объектов БД, таких как схема данных, отдельные таблицы, представления, функции, типы, роли и т.п., с их распределением по отдельным файлам в соответствующей структуре базы иерархии директорий;
- Извлечение отдельных элементов схемы, таблиц, функций;
- Фильтрация содержимого с использованием регулярных выражений;
- Интеграция с SVN и Git для отслеживания изменений в БД;URL: http://comments.gmane.org/gmane.comp.db.postgresql.announce/...
Новость: http://www.opennet.me/opennews/art.shtml?num=34137
Это партянка, состоящая из 1 файла размером в 1000 строк с огромными if/else блоками и копипастами внутри. Естественно без юнит тестов.
И что Вы порекомендуете в качестве альтернативы для этих целей?
Отлично, посмотрим. Как раз собирался для тех же целей изобретать свой велосипед, а тут вон оно уже.Только мне нечто относительно универсальное нужно. Кто-нибудь знает такую же штуку для мускула?
что такое мускул?
> что такое мускул?мускул - это в некоторых случаях неплохая, а часто ещё и гораздо более популярная, альтернатива обсуждаемому тут писквелу.
А зачем ты коверкаешь названия?
> А зачем ты коверкаешь названия?Меня использовать такие слова в разговорной речи семь лет назад один хороший человек научил, который любил флеймы по теме. Не выговаривать же многосложное "пост-гре-эс-ку-эль". Мускуль, пискль - и всё, очень удобно, очень быстро произносится. А как Вы их читаете?
Запомни, о юный падаван: пискль у тебя в штанах, а СУБД называется Постгрес! ;-)
MySQL не полностью ACID. А когда вопрос касается амбулаторных карт пациентов сотен больниц - это критично (абсолютно критично). Одно протерянное/неверное значение в одной из таблиц в одной из 10 датабаз может стоит кому-то жизни/здоровья/просто_нервов. В Постгрес-Слоно-Кластере при правильной настройке древовидной репликации (в том числе реверсивной) это просто исключено. Особенно, если ваш ребёнок (мой случай) постоянно наблюдается в педиатрии одной из этих больниц. Не сравнивайте, пожалуйста, плотный энтерпрайз с сайто-продакшном.
> MySQL не полностью ACID. А когда вопрос касается амбулаторных карт пациентов сотен
> больниц - это критично (абсолютно критично). Одно протерянное/неверное значение в одной
> из таблиц в одной из 10 датабаз может стоит кому-то жизни/здоровья/просто_нервов.
> В Постгрес-Слоно-Кластере при правильной настройке древовидной репликации (в том числе
> реверсивной) это просто исключено. Особенно, если ваш ребёнок (мой случай) постоянно
> наблюдается в педиатрии одной из этих больниц. Не сравнивайте, пожалуйста, плотный
> энтерпрайз с сайто-продакшном.Вопрос был не в том, никто не утверждал, что мускул способен тягаться прям вот на всех фронтах. Вопрос был в том, есть ли нечто подобное уже готовое для мускула? Поскольку задачу надо решать и для него тоже.
У Вас не совсем точные данные: MySQL поддерживает несколько движков для хранения данных; MyISAM, который является наиболее популярным (и быстрым, из тех, что хранят данные на диске), действительно свойствами ACID не обладает, однако встроенный же движок InnoDB вполне себе ACID: http://dev.mysql.com/doc/refman/5.0/en/innodb-storage-engine...
Естественно, он по понятным причинам медленнее, однако таки "энтерпрайз".Другой вопрос, что есть более стрёмные косяки, типа молчаливого обрезания данных в некоторых случаях. Тут MySQL прямо родной брат PHP. Как будто одни и те же люди делали.
Спасибо за ссылку, оплошал!
> Другой вопрос, что есть более стрёмные косяки, типа молчаливого обрезания данных в
> некоторых случаях. Тут MySQL прямо родной брат PHP. Как будто одни и те же люди делали.Добавим сюда, что InnoDB не поддерживает полнотекстовый поиск, который есть только в MyISAM - не всем, конечно, надо, но тем не менее вилка, если нужен (а обычно там, где он нужен - это серьёзный проект и там же нужен и ACID).
> MySQL не полностью ACID. А когда вопрос касается амбулаторных карт пациентов сотен
> больниц - это критично (абсолютно критично). Одно протерянное/неверное значение в одной
> из таблиц в одной из 10 датабаз может стоит кому-то жизни/здоровья/просто_нервов.
> В Постгрес-Слоно-Кластере при правильной настройке древовидной репликации (в том числе
> реверсивной) это просто исключено. Особенно, если ваш ребёнок (мой случай) постоянно
> наблюдается в педиатрии одной из этих больниц. Не сравнивайте, пожалуйста, плотный
> энтерпрайз с сайто-продакшном.Куда там ACID? Там даже триггеры каскадно не срабатывают!
Что в сумме убивает идею реализации на уровне базы сколько-нибудь серьёзной логики управления целостностью и требует лепить костыли на уровне скриптов, что надёжности не добавляет. И это попадалово даже для сайтостроения (если, конечно, не делать сайт на три странички).Решительно не понимаю популярности MySQL. Он проще? Да Боже упаси, то нельзя, это не работает, а вот то-то даже в планах нет - выкручивайся среди этого.
Разница между MySQL и Postgres как между запорожцем и мерседесом. Вроде и то, и то - ездит, но вот скорость и ощущения от езды...
Однако в отличие от машин, обходятся они в те же деньги, то бишь бесплатны. Смысл тратить время на менее качественный продукт?
Ни коим образом не нужно (насколько мне зе 4 года раоты с Постгрес (включая Слоны-кластеры) работать приходилось). ибо дампы парсятся чистой перлой намного проще, а для любителей ГУИ - там кто-то до сих пор phpMyAdmin от уязвимостей лечит, но к продакшену ACID-несовместимые СУБД "тоже конечно относятся";)
> Ни коим образом не нужно (насколько мне зе 4 года раоты с
> Постгрес (включая Слоны-кластеры) работать приходилось). ибо дампы парсятся чистой перлой
> намного проще, а для любителей ГУИ - там кто-то до сих
> пор phpMyAdmin от уязвимостей лечит, но к продакшену ACID-несовместимые СУБД "тоже
> конечно относятся";)Тут перл и есть, просто написано уже. Лично мне оно нужно для случая трёх десятков баз на некоем подобии "хостингов для своих", правлю которые не я, зато примерно раз в месяц приходится разгребать последствия бездумного внесения изменений в них.
Иногда речь только про структуру БД и процедуры, иногда же приходится смотреть даже за изменениями данных в определённых таблицах. Навешивать свои механизмы ведения истории поверх существующих баз не имею возможности.