А вот при эксплуатации, это весьма стабильная СУБД. В 99,9% она и внезапное отключение питания переживет без повреждения базы. IMHO в условиях когда оборудование ненадежно, у нее вообще конкурентов нет.
Сомневаюсь, что сейчас можно начать разработку под MS SQL 2012. А пот третий FB — пожалуйста. Но выйдет он еще не скоро. Я и говорю о том, что imho разрабатывать лучше всего под stable продукт. В случае с FB это 2.5, а в случае с MS SQL 2008R2. А стремиться обогнать время — не самый лучший вариант.
Я предпочитаю не делать опасные, с этой точки зрения, операции. На всякий случай. После изменения типа столбца всегда привожу записи к новому виду. К тому же, контрольный backup-restore позволяет избежать таких проблем еще на стадии разработки.
А вот я, почему-то предпочитаю работать со стабильными продуктами. К тому же, перерывы между версиями FB слишком велики: можно разработать продукт и год ждать стабильного релиза.
Ну-ну. А Вы, стало быть, восторженный фанат firebird-а.
К Вашему сведению, я работаю с firebird-ом с момента выхода версии 1.5. В данный момент работаю над кластером БД на базе firebird 2.1 в довольно серьезном проекте. Просто я предпочитаю здраво смотреть на продукт и видеть в нем как преимущества так и недостатки. И, если для некоторых проектов FB — отличное решение, то для других он совершенно не подходит. А фанатеть от чего-либо — это не по мне. Я предпочитаю голову включать и трезво оценивать продукт с точки зрения требований к проектируемой системе.
Дальше в этой ветке писать не буду: обсуждение превращается во флейм. Исходную мысль о том, что сделать невосстановимый бэкап можно легко и просто, imho донес предыдущими постами.
Мне бы хотелось, чтобы появилась возможность одновременно пользоваться привилегиями двух ролей, если пользователь является их членом. Как в MS SQL, например. Пока можно только залогиниться с указанием только одной конкретной роли. Делать это в третьей версии не собираются. Зато в третьей версии введут изменения в trusted autentification и роль будет назначаться пользователю в зависимости от группы пользователей домена. А если пользователь является членом двух групп, каждой из которых сопоставлена своя роль, то в базу данных он вообще попасть не сможет, так как получит исключение при входе. IMHO хрень полная.
Перейдите по ссылке www.firebirdfaq.org/faq103/ (я ее приводил уже выше) и почитайте как делают это разработчики firebird-а. Если не ошибаюсь, за справочную документацию в firebird-е отвечает госпожа Helen Borrie. Полагаю, что FAQ было написано, как минимум, при ее участии.
Что еще считать официальным способом, как не описание на официальном сайте? (Вопрос риторический, отвечать не обязательно :)
К тому же, второй предложенный способ сделать невосстановимый бэкап не использует служебные таблицы вообще. :)
Судя по прошедшей недавно третьей конференции разработчиков Firebird, значительно лучше он не станет. Будет устранены архитектурные проблемы, а вот что касается расширения SQL и некоторых прочих необходимых вещей — они не в приоритете. Будем ждать 4 версии. :)
Единственный официальный способ установить столбцу ограничение Not Null. :) Alter Table, в этом случае, не поддерживается, за что отдельное спасибо разработчикам firebird :)
Впрочем, если не нравится такой способ, просто добавьте новый столбец Not Null в таблицу:
ALTER TABLE «Test» add «Problem1» integer NOT NULL;
С тем же результатом и тем же пруфлинком. :)
На самом деле, сделать невосстановимый бэкап достаточно просто. Для этого не надо физически портить файл. Все может быть сделано средствами самого firebird-а. Например, так:
1. Создадим таблицу со столбцом Note, который может принимать значения null
CREATE TABLE «Test» (ID INTEGER NOT NULL, «Note» VARCHAR(15));
2. Добавим запись с null-ом
ALTER TABLE «Test» ADD CONSTRAINT «PK_Logs» PRIMARY KEY (ID);
INSERT INTO «Test» (ID, «Note») VALUES (1, null);
3. Установим столбцу Note ограничение not null.
UPDATE RDB$RELATION_FIELDS SET RDB$NULL_FLAG = 1 WHERE RDB$FIELD_NAME = 'Note' AND RDB$RELATION_NAME = 'Test';
К Вашему сведению, я работаю с firebird-ом с момента выхода версии 1.5. В данный момент работаю над кластером БД на базе firebird 2.1 в довольно серьезном проекте. Просто я предпочитаю здраво смотреть на продукт и видеть в нем как преимущества так и недостатки. И, если для некоторых проектов FB — отличное решение, то для других он совершенно не подходит. А фанатеть от чего-либо — это не по мне. Я предпочитаю голову включать и трезво оценивать продукт с точки зрения требований к проектируемой системе.
Дальше в этой ветке писать не буду: обсуждение превращается во флейм. Исходную мысль о том, что сделать невосстановимый бэкап можно легко и просто, imho донес предыдущими постами.
Что еще считать официальным способом, как не описание на официальном сайте? (Вопрос риторический, отвечать не обязательно :)
К тому же, второй предложенный способ сделать невосстановимый бэкап не использует служебные таблицы вообще. :)
Впрочем, если не нравится такой способ, просто добавьте новый столбец Not Null в таблицу:
ALTER TABLE «Test» add «Problem1» integer NOT NULL;
С тем же результатом и тем же пруфлинком. :)
(Имейте в виду: Хабр кавычки меняет на парные)
1. Создадим таблицу со столбцом Note, который может принимать значения null
CREATE TABLE «Test» (ID INTEGER NOT NULL, «Note» VARCHAR(15));
2. Добавим запись с null-ом
ALTER TABLE «Test» ADD CONSTRAINT «PK_Logs» PRIMARY KEY (ID);
INSERT INTO «Test» (ID, «Note») VALUES (1, null);
3. Установим столбцу Note ограничение not null.
UPDATE RDB$RELATION_FIELDS SET RDB$NULL_FLAG = 1 WHERE RDB$FIELD_NAME = 'Note' AND RDB$RELATION_NAME = 'Test';
Вуаля. Мы получили базу, бэкап которой будет невосстановимым. :)
Пруфлинк: www.firebirdfaq.org/faq103/