ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / FireBird 1.5.2 vs PostgreSQL 7.4
25 сообщений из 113, страница 3 из 5
  3  все
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865694
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ASCRUSНо вот зачем человеку рекомендовать то, что заведомо ему неподходитУверен ?
"Это отдает фанатизмом, а не здравым смыслом" (c) ASCRUS
...
Рейтинг: 0 / 0
14.01.2005, 17:31
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865701
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Александр ГoлдунНикак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком. И при этом придумывают протоколирования действий на триггерах, какие-то исскуственные схемы для реализации наката.

Саш, ну ты-то хоть не путай народ. Ты ведь говоришь про redo log, а фанаты - про undo. Необходимость второго в версионнике - нонсенс. А вот первый весьма бы не помешал для incremental recovery. И с этим никто не спорит, собственно.
...
Рейтинг: 0 / 0
14.01.2005, 17:36
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865726
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
hvlad ASCRUSНо вот зачем человеку рекомендовать то, что заведомо ему неподходитУверен ?
"Это отдает фанатизмом, а не здравым смыслом" (c) ASCRUS
Во первых мы на "ТЫ" вроде как не переходили. Во вторых переход на личности осуществляется участниками за недостатком аргументов (это к слову о предыдущих на меня выступлениям по поводу пенсии). В третьих полностью уверен благодаря приведенным в данном топике примерам. В четвертых цитировать кого либо мало - необходимо вдумываться. Ну и в последних - я не очень понимаю, чего так реагировать, вроде как никто интербейсников в ущербности продукта не обвинял, всего лишь перечислили факты и каждый для себя сделал соотвествующие выводы, откуда такой возник комплекс неполноценности лично у Вас - ведь другие специалисты Interbase в этом топике вроде как адекватно реагируют на все высказывания, признают недостатки и подчеркивают его достоинства.
...
Рейтинг: 0 / 0
14.01.2005, 17:52
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865731
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
dimitr Александр ГoлдунНикак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком. И при этом придумывают протоколирования действий на триггерах, какие-то исскуственные схемы для реализации наката.

Саш, ну ты-то хоть не путай народ. Ты ведь говоришь про redo log, а фанаты - про undo. Необходимость второго в версионнике - нонсенс. А вот первый весьма бы не помешал для incremental recovery. И с этим никто не спорит, собственно.

Сам прочитал и ужаснулся, как сгустил краски ;)))

Да, я про redo, а не undo. Но undo - это чисто технический момент и он меня, как пользователя сервера БД, не очень интересует, как он откатит транзакцию - лишь бы откатил. А вот без практического потребительского использования redo жить не могу.

IMHO у FB главное преимущество - местное сообщество его пользователей и свои же родные разработчики, с которыми можно тут же пообщаться, как вот с тобой, например ;) И которые, как ни странно, наиболее критично из всего FB-сообщества относятся к этому серверу.
Но это в первую очередь потенциал на будущее. А пока FB еще есть куда расти.

Кстати, вопрос: в FB2 уже будет распараллеливание запросов при общем кэше?
...
Рейтинг: 0 / 0
14.01.2005, 17:57
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865761
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ASCRUSВо первых мы на "ТЫ" вроде как не переходили. imho это общепринято, ок, будем на Вы (если вообще будем)

ASCRUSВо вторых переход на личности осуществляется участниками за недостатком аргументов (это к слову о предыдущих на меня выступлениям по поводу пенсии).Это Вы про что ?

ASCRUSВ третьих полностью уверен благодаря приведенным в данном топике примерам.Ок

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

ASCRUSНу и в последних - я не очень понимаю, чего так реагировать, вроде как никто интербейсников в ущербности продукта не обвинялМне что - опять цитировать ? ;)
И где с моей стороны "такая" реакция ?

ASCRUS всего лишь перечислили факты и каждый для себя сделал соотвествующие выводыФактов практически не было

ASCRUSоткуда такой возник комплекс неполноценности лично у Вас - ведь другие специалисты Interbase в этом топике вроде как адекватно реагируют на все высказывания, признают недостатки и подчеркивают его достоинства.У Вас ещё и диплом психоаналитика ?

Все вопросы - риторические, можно не отвечать
...
Рейтинг: 0 / 0
14.01.2005, 18:12
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865892
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Страшен пятничный флейм, бессмысленный и беспощадный (с)

ЗЫ. Это я вместо финала ;-) Хотя шибко сомневаюсь, что автору топика мы сильно помогли...
...
Рейтинг: 0 / 0
14.01.2005, 20:36
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865915
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
А почему выбор именно между FireBird 1.5.2 и PostgreSQL 7.4?

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


Оба упомянутых сервера бесплатны. Но если проект коммерческий, то может есть смысл не ограничиваться этими серверами, а расмотреть еще и коммерческие и все тщательно взвесить?
В моей личной практике в большинстве проектов стоимость сервера компенсировалась с лихвой уменьшением стоимости разработки и сопровождения по сравнению с использованием бесплатных серверов.
...
Рейтинг: 0 / 0
14.01.2005, 21:08
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866058
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
Странно, почему-то Sad Spirit отсутствует :), тема самая что ни на есть его! (наверное после праздников все никак не отойдет)

...
Рейтинг: 0 / 0
15.01.2005, 00:43
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866262
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
Рыжий КотСтранно, почему-то Sad Spirit отсутствует :), тема самая что ни на есть его! (наверное после праздников все никак не отойдет)

Спасибо за трогательную заботу о моём здоровье. ;)

На самом деле просто времени нет за развитием флейма следить, тем более тут уже профессионалы развлекаются, а я так --- любитель. ;)

Gold
Тогда получается что если Postgres и другие серверы учитывают все вышеперечисленные показатели, то подготовка запросов сильно тормозит в этих серверах? Также не понятно мне с кэшированием команд. Как кэширование команд увязывается с генерированием разных планов на каждую команду?

Угу, подготовка "тормозит", зато выполнение ускоряется. ;) А с кэшированием действительно могут быть проблемы, если для разных значений, подставляемых в закэшированный запрос, сильно отличается распределение данных, про это в доках написано

dimitr
Процент заюзанности Постгреса в реальных задачах далек от IB и всех его последователей. Тем паче в коммерческой сфере. Возможно, фанатиков-энтузиастов там тоже меньше. Поэтому и меньше воплей, как "за", так и "против". Полагаю, что отсюда же меньше информации о стабильности, багах и прочих граблях.
Слова насчёт процента заюзанности неплохо бы подтвержать ссылками на какую-никакую статистику. В коммерческой сфере: PostgreSQL сейчас поддерживают Red Hat, Fujitsu и совсем недавно Pervasive. Про фанатиков --- чистая правда: как в интернете не устроят опрос про "любимую OpenSource СУБД" --- с большим отрывом выигрывает Firebird. ;)

mozheyko_d
А чё за грабли?

Была куча всяких неприятных ограничений: из-за отсутствия лога транзакций данные в таблицу принудительно скидывались после каждого COMMIT'а, размер строки был ограничен 8кб, операция сборки мусора полностью блокировала таблицу. Где-то с версии 7.3 таких ограничений уже не было и продукт стал вполне пригоден к весьма серьёзной эксплуатации. Версия 7.3 вышла в конце 2002, оставим вопрос "а где тогда были остальные OpenSource СУБД" в качестве упражнения для читателей.

к исходному вопросу, скажу за PostgreSQL:
mef
-устойчивость
-производительность при описанных условиях

судя по имеющемуся описанию, на нормальном железе всё это будет работать вполне нормально.


-масштабируемость (обработка нитями - грубо говоря типовая конфигурация железа - на 500 ниток, если надо 600 - докупаем ещё один сервак, регистрируем в системе - и вперёд)

полноценной multi-master репликации нету и вряд ли будет до версии 8.1.
Но вертикальная масштабируемость хорошая, так что можно просто поставить более мощный сервер.


-удобство разработки (в идеале - визуальные среды разработки запросов и ХП)

Это вряд ли. :)

Кроме того, я где-то что-то слышал про процедурный язык pl/r для PostgreSQL, он вроде бы специально приспособлен для такой обработки, о которой шла речь в исходном сообщении.
...
Рейтинг: 0 / 0
15.01.2005, 12:59
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866296
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
[quot Sad Spirit]
...
Но вертикальная масштабируемость хорошая, так что можно просто поставить более мощный сервер.

[quot ]

А что, уже выпустили Embedded Posgres, такой как в FB?
...
Рейтинг: 0 / 0
15.01.2005, 14:03
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866807
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mv
Участник
Уважаемый mef !
Описанные в начале ветви требования эмулируются с вполне допустимыми трудозатратами.
Впрочем, может быть, спросивший mef больше интересуется психоанализом, чем техническими особенностями выбираемого инструментального средства.

Я активно использовал совсем немного СУБД - FoxPro (ну, не СУБД, но очень похоже), Access, InterBase и MS SQL. Несмотря на сегодняшнюю мою приверженность к InterBase не могу сказать, что хотя бы одна из перечисленных система не удовлетворяла моих потребностей на момент ее использования .

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

Более того, если здесь Вы спросите по поводу того, что один из результатолв тестов не удовлетворяют Вас в чем-то, то здесь Вы моментально получите совет и рекомендацию. Только спрашивать об InterBase нужно в разделе InterBase, а о MS SQL - в разделе MS SQL.
...
Рейтинг: 0 / 0
16.01.2005, 20:35
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866838
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
hvlad.
+++++++++++++++++++++++++
На SQL.ru принято обращаться на "Вы". За исключением форумов Просто Треп и AREA-51.
...
Рейтинг: 0 / 0
16.01.2005, 22:55
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867213
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, Cat2!
Ты пишешь:

Cat2C> На SQL.ru принято обращаться на "Вы".
За исключением форумов Просто Треп и AREA-51.
Опять, Кот, самодурствуешь?!
Где это в правилах?!
Нету?
Ну и нех!

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
17.01.2005, 10:53
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867225
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Cat2hvlad.
+++++++++++++++++++++++++
На SQL.ru принято обращаться на "Вы". За исключением форумов Просто Треп и AREA-51. Это не отражено в правилах форума, посему каждый выбирает форму обращения по своему разумению.
Если собеседник возражает, это его право. Ничего оскорбительного я в этом не вижу.
...
Рейтинг: 0 / 0
17.01.2005, 10:55
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867273
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я понял, что версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки, то есть поддерживается версионность для изменений записи ? Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?

Я понимаю версионность Оракла в том плане, что она позволяет во время изменения записи читателям работать с ее оригинальной версией, но писатели там друг друга блокируют (что есть правильно). Но вот зачем делать версионность писателей и из за этого получать такую сложную модель физической реализации движка я понять не могу. Буду очень признателен, если просветите по этому вопросу или же поправите меня там, где я ошибаюсь. Как говорится учиться ни когда не вредно, во всяком случае меня интересуют различные модели реализации поддержки уровней изоляции в блокировочниках и версионниках, их механизмы работы и достоинства и недостатки. Пока вот для меня модель версионности Interbase загадка, хотя я честно почитал на эту тему различную литературу, выложенную на ibase.ru и вроде как чего то понял.
...
Рейтинг: 0 / 0
17.01.2005, 11:06
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867299
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, ASCRUS!
Ты пишешь:

ASCRUS A> Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я
понял, что
A> версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки, то есть поддерживается версионность для
A> изменений записи ? Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?
http://www.ibase.ru/devinfo/versions.htm

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
17.01.2005, 11:13
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867416
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ASCRUSКстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я понял, что версионность в нем означает, что на DML команды нет понятия эклюзивной блокировкиВ том смысле, как в MS - нет такого понятия, ибо оно не нужно.

ASCRUSто есть поддерживается версионность для изменений записи ?Нет.

ASCRUS Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?Ага

В любой момент времени может быть не более одной активной версии записи. Версия активна, если создавшая её тр-ция не находится в состоянии commited. Каждая версия каждой записи помечена номером создавшей её тр-ции. Движок знает о состоянии всех тр-ций в любой момент времени.

Если кто-то пытается создать вторую активную версию записи, то он либо ждёт завершения конкурирующей активной тр-ции, либо сразу получает ошибку lock conflict on no wait transaction. Это зависит от пар-ра wait\no wait тр-ции.

Штатно можно зарезервировать (заблокировать) всю таблицу от чтения и\или записи.
Запись можно "заблокировать" от изменений, просто проапдейтив её. "Блокировка" будет снята после завершения тр-ции.
В FB1.5 ввели спец. конструкцию SELECT .. WITH LOCK, делающую холостой апдейт записи в момент её фетча и не приводящий к срабатыванию триггеров.

PS Ничего, что я цитирую ? ;)
...
Рейтинг: 0 / 0
17.01.2005, 11:51
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867464
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторPS Ничего, что я цитирую ? ;)
Наоборот, спасибо. Приведенную выше ссылку я уже читал, но решил, что лучше уточнить, чем делать выводы исходя из того, что понял :) Все таки тяжеловатый механизм - версионность индексов это конечно круто, кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?
...
Рейтинг: 0 / 0
17.01.2005, 12:10
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867490
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ASCRUS версионность индексов это конечно круто, кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?
Хм. Боюсь, я не очень понимаю, в чем разница. Разница с архитектурой Oracle, судя по указанной статье - "старая версия записи" пишется куда-то в data file, в то время как Oracle использует rollback segment. А Oracle спокойно использует "кластерные индексы" - соответственно, механизм работает. Как именно - сходу не скажу, надо смотреть доки.
...
Рейтинг: 0 / 0
17.01.2005, 12:20
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867496
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Кластерный индексов действительно нет и их действительно сделать затруднительно. Да и насчет обычных индексов есть неприятные ограничения. Сейчас хранится один ключ индекса на все версии записи (ID транзакции в ключ не входит). Отсюда невозможность index-only scan, ибо для каждого выбранного ключа придется читать запись с диска и определять видимость для текущей транзакции. Можно сделать полную версионность в индексе, введя в ключ txn ID, но это приведет к модификации всех индексов при каждом изменении записи, даже если затронуты неиндексированные поля. Пока считается, что это слишком большая цена. Да и последующая сборка мусора в таком "загаженном" индексе будет заметно тяжелее, чем сейчас. Вот такова селяви насчет индексов в версионнике.
...
Рейтинг: 0 / 0
17.01.2005, 12:24
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867568
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ASCRUSВсе таки тяжеловатый механизм - версионность индексов это конечно крутоА кто тут говорил про версионность индексов ? ;)
Индексы - отдельная песня. Версий там нет. Когда появляется новый ключ (insert\update ключевых полей), он вставляется в b-tree. И всё.
Любой индексный метод доступа должен, после построения списка номеров записей-кандидатов, посетить запись и убедиться что она все ещё удовлетворяет критерию отбора и может быть видна читающей тр-ции.

На перый взгляд это снижает полезность индексов. Но такое построение, вместе с префиксным сжатием ключа, позволяет очень компактно хранить индексы на диске. Я как-то сравнивал с MS - выигрыш был в 2-3 раза на одних и тех же данных. Это значительно снижает потребность в дисковых операциях.

Единственный минус - невозможность использования индексного покрытия.

ASCRUSкстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?Их нет потому что они не дадут столь большого выигрыша в призводительности, как у других серверов.
В FB любой индексный метод доступа сначала сканирует индекс, а потом читает таблицу. Причём таблица читается в порядке номеров страниц, т.е. как кластерная таблица у MS.
...
Рейтинг: 0 / 0
17.01.2005, 12:51
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867583
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
softwarerХм. Боюсь, я не очень понимаю, в чем разница. Разница с архитектурой Oracle, судя по указанной статье - "старая версия записи" пишется куда-то в data file, в то время как Oracle использует rollback segment.

Оракл хранит не версии записей, а версии блоков, насколько я в курсе. Вот в Юконе версионность ближе к IB/FB, но и там версии лежат в tempdb, а не в основной базе.

softwarerА Oracle спокойно использует "кластерные индексы" - соответственно, механизм работает. Как именно - сходу не скажу, надо смотреть доки.

Мне кажется, тут проблема в производительности. Перелопачивать index organized table при каждом незакоммиченном изменении ключа... а потом перелопачивать обратно при сборке мусора после роллбека...
...
Рейтинг: 0 / 0
17.01.2005, 12:55
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867608
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
hvladПричём таблица читается в порядке номеров страниц, т.е. как кластерная таблица у MS.

Кстати, этот нюанс - вроде как один из плюсов IB/FB против Оракла. Я специально делал замеры и вышел на вывод, что сортировку битмапа с DBKEY-кандидатами Оракл не производит. Сканирование с INDEX-планом на неуникальном индексе FB выполняет в два-три раза быстрее (при неполном кешировании данных сервером, есс-но), чем оракловый RANGE INDEX SCAN. Возможно, отсюда сильная нелюбовь ораклового оптимизатора к RANGE SCAN - обычно выбирается либо UNIQUE SCAN (при возможности), либо HASH JOIN. Возможно, кто-либо здесь подтвердит или опровергнет это наблюдение.
...
Рейтинг: 0 / 0
17.01.2005, 13:03
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867726
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
dimitrОракл хранит не версии записей, а версии блоков, насколько я в курсе.
Это так. Но я не вижу тут идеологически существенной разницы - имхо это технический момент. Плюс такого подхода, по моим представлениям, в том, что версионность получается как бы автоматической для всех объектов данных - ну и еще в том, что когда-то, до знакомства с Oracle, я писал движок на том же принципе :) Но версионность по записям вроде бы не мешает сделать то же.

dimitrМне кажется, тут проблема в производительности. Перелопачивать index organized table при каждом незакоммиченном изменении ключа... а потом перелопачивать обратно при сборке мусора после роллбека...
Хм. Я бы отметил так:

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

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

- перелопачивать index organized table или просто индекс - хм, не такая уж принципиальная разница. Единственно что IOT скорее всего в среднем значительно шире - но вопрос, какую роль это играет (я не помню сходу, делаются ли там "цепочки" или переносится полная запись).

- Перестраивать индекс при изменении данных все равно необходимо. Когда делать это - то ли при изменении данных, то ли при commit-е - вряд ли принципиально с точки зрения производительности именно этой операции. Зато версионный индекс может крайне ускорить работу, а IOT - как минимум, существенно экономит место и чтения.

Итог: разумеется, при неудачном использовании будут тормоза. Сделать вроде как можно, и использовать во благо - тоже.
...
Рейтинг: 0 / 0
17.01.2005, 13:38
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867779
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
dimitrЯ специально делал замеры и вышел на вывод, что сортировку битмапа с DBKEY-кандидатами Оракл не производит.
В Oracle довольно много написано по поводу CLUSTERING_FACTOR - полагаю, это именно то, что Вы искали. Так и есть - документация подчеркивает, что индексный доступ может привести к многократному чтению одного блока таблицы.

dimitrВозможно, отсюда сильная нелюбовь ораклового оптимизатора к RANGE SCAN - обычно выбирается либо UNIQUE SCAN (при возможности), либо HASH JOIN.
Хм. Это зависит от настроек и статистики, вряд ли возможно сформулировать такие простые и четкие правила. Если говорить об OLTP - RANGE SCAN лично я видел куда чаще, нежели HASH JOIN - возможно, из-за того, что последний потребляет относительно много памяти.

RANGE SCAN - операция, более тяготеющая к оптимизации FIRST_ROWS, HASH/MERGE JOIN - более тяготеющая к ALL_ROWS. С точки зрения FIRST_ROWS нежелание сортировать индекс полностью понятно, как понятно и нежелание тратить на это память. Нужен ли механизм доступа по rowid-сортировке в дополнение к существующим - не знаю и сходу не вижу способа найти однозначный ответ.
...
Рейтинг: 0 / 0
17.01.2005, 13:53
| Ответить | Цитировать | Написать  
25 сообщений из 113, страница 3 из 5
  3  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / FireBird 1.5.2 vs PostgreSQL 7.4
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]