LINUX.ORG.RU

Конференция по Firebird в Днепропетровске!

 , , , ,


0

0

23его апреля этого года пройдёт первая украинская меджународная конференция, посвящённая РСУБД с открытым кодом Firebird. Со своими докладами выступят ведущие разработчики Firebird. Также будут представлены доклады о популярных инструментах, используемых при создании и обслуживании информационных систем. Выступят ведущие специалисты таких известных компаний как Devrace, IBSurgeon, FastReport.

Конференция бесплатная, однако требуется регистрация.

Конференция будет проходить по адресу: Национальный горный университет (пр. Карла Маркса 19), корпус № 1, зал заседаний ученого совета (3 этаж, 104 аудитория).

Планируется проведение On-line трансляции при помощи Microsoft Live Meeting. Будет доступен звук, презентация и видео (без записи со стороны слушателя).

>>> Программа конференции, схема проезда и многое другое

★★★★★

Проверено: maxcom ()
Последнее исправление: helios (всего исправлений: 1)

фигасе, сходить что-ли...

23его


:/

k0l0b0k ★★
()

А почему все говорят РСУБД, когда на самом дела СУРБД?

anonymous
()

куда-нить в сибирь не хотите перенести? я бы тоже сходил :)

bernd ★★★★★
()

> в Днепропетровске!

неожиданно, но приятно)

kelyar ★★★★★
()

Да, с Microsoft Live Meeting это порадовали. Не знаю в точности все его фичи, но предполагаю что ustream.tv может быть ему альтернативой.

teslaua
()
Ответ на: комментарий от maxcom

>почему делфи?

Потому что раньше Interbase был и использовали его в основном кодеры на делфи. После открытия кода и переименования в Firebird контингент кодеров работающих с этой базой по-моему не изменился. Сама база вроде ничего, но конференция будет состоять из 99% виндузятников (Microsoft Live Meeting же).

anonymous
()
Ответ на: комментарий от anonymous

Ты абсолютно прав! И ещё эти «известные фирмы» - делфи...

anonymous
()

бормана на вас не хватает )

bernd ★★★★★
()
Ответ на: комментарий от boo32

> это же про делфи что-то. что-то глючное.

Маленький, толстенький, зелененький... ЗАПОМНИ, НЕДОЛРОСЛЬ - ТРОЛЛИТЬ ТУТ МОЖНО ТОЛЬКО СО ВТОРОЙ ЗВЕЗДЫ!!!

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Маленький, толстенький, зелененький... ЗАПОМНИ, НЕДОЛРОСЛЬ - ТРОЛЛИТЬ ТУТ МОЖНО ТОЛЬКО СО ВТОРОЙ СЕРОЙ ЗВЕЗДЫ!!!

/FTFY

fat_angel ★★★★★
()
Ответ на: комментарий от no-dashi

>ТРОЛЛИТЬ ТУТ МОЖНО ТОЛЬКО СО ВТОРОЙ ЗВЕЗДЫ!!!

брехня :-)

anonymous
()

> ведущие специалисты таких известных компаний как Devrace, IBSurgeon, FastReport

широко известные в узких кругах :)))

это поделие все так же кончает базу без видимых на то причин? я еще понимаю дельфистов - им оно практически, насильственным образом впарено, но остальные то? или никто, кроме дельфистов этим и не пользуется?

Momyc
()
Ответ на: комментарий от Momyc

Используем это «поделие» уже 9 лет в автоматизированной системе университета. 209 таблиц, 368 процедур, 127 представлений и прочих радостей по мелочи. За все время НИ ОДНОГО СБОЯ! Эксплуатируем на CentOS (сначала 4, потом 5). Пакет компилируем сами из src.rpm.

awdd
()
Ответ на: комментарий от Momyc

Кстати, может так «повезло», но с Postgres имели проблем больше, чем с Firebird. От версии к версии продукт становится заметно лучше. Возможно, не самая лучшая СУБД, есть определенные недостатки, но для большинства наших задач подходит великолепно. Наша база построена так, что практически все состояния вычисляются на основе временнЫх срезов. Например, список студентов группы каждый раз вычисляется на основе приказов отдела кадров. Большинство подобных вычислений занимает не более 500-700 мс. Коллеги, с которыми приходилось сталкиваться, удивлялись, «неужели Firebird у вас все это тянет»? Тянет. Правда для этого приходится тщательно продумывать структуру данных, ну и конечно же структуру запросов.

awdd
()

Ооооо... Жечь огнёёёёёёёёёёёёёёёёём!

AngryElf ★★★★★
()
Ответ на: комментарий от awdd

> Правда для этого приходится тщательно продумывать структуру данных, ну и конечно же структуру запросов.

Можно подумать что в каком нибудь оракле об этом можно и не думать - все продумывается само...

anonymous
()
Ответ на: комментарий от awdd

фффтопку

Firebird отсутствует
1. SMP поддержка
2. лог транзакций

Firebird присутствует
1. мегобаг «cursor stability» в результате декларативный SQL превращен в какое-то процедурное порно
2. блокировочный RC, не обеспечивающий консистентность набора

вывод: примитивный MySQL уже на года опережает FB и по другим принципиальным направлениям. оптимизатор, раздельный лог под версии, полноценный кеш блоков и запросов и т.п.

anonymous
()
Ответ на: комментарий от iZEN

товарищ совсем блондинко ?

у ФБ есть две архитектуры суперсервер - единый процесс, юзать может только одно ядро проца и класик - порно запускающее тучу процессов в надежде, что шедулер оси раскидает хотя бы часть из них по разным процам. туча процессов класик архитектуры ничего не связывает, нет даже единого кеша. нормальный SMP супорт планировался добавить в ФБ 3.0, релиз которого анонсировался на 2006 год ...

Сама СУБД Firebird имеет версионную архитектуру.


блондинко бы почитал о транзакциях хоть, что нибудь. спутать лог транзакций с version storage/mssql он же UNDO/oracle это сильно.

anonymous
()
Ответ на: фффтопку от anonymous

>Firebird отсутствует >1. SMP поддержка

Как вам там в криокамере?

2. лог транзакций

На порхуа он нужен? У нас за 10 лет один сбой приведший к некритическим потерям данных. В помощь зеркалирование и флаг sync принудительной записи на винт - если конечно у вас, многоуважаемый анонимус не транзакционная БД.

Firebird присутствует >1. мегобаг «cursor stability» в результате декларативный SQL превращен в какое-то процедурное порно

сам-то понял что сказал? Про этот «мегабаг» не слышал и писать на стандартом SQl-99 запросы в приложениях мне почему-то не мешает...

2. блокировочный RC, не обеспечивающий консистентность набора

Воспользовался возможностью «блеснуть» знаниями?

вывод: примитивный MySQL уже на года опережает FB ... и т.п.

Начнем с того, что у FB есть оптимизатор. Закончим, тем, что это настоящая СУБД, а не хренилице данных для ВЭБ морды. FB одной из первых, - если не первая, - реализовала мноверсионность транзакций, которой у MySQL в помине нет и скорее не будет. Далее, триггера и хранимые процедуры (ХП). Среди новинок гетерогенные запросы встроенные в ХП. В будущих версиях обещают гетерогенные запросы в SQL.

Мгновенно выдают результат в базах размером 20-30 GB по запросам в таблицах с 10 млн. записей.

Короче, классная СУБД.

voodix
()
Ответ на: комментарий от anonymous

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

Нет, по-твоему, приложение должно само раскидывать свои процессы/потоки по ядрам процессора вместо операционки? Может ещё задавать приоритет? Ты не болен случайно?

Сама СУБД Firebird имеет версионную архитектуру.


блондинко бы почитал о транзакциях хоть, что нибудь. спутать лог транзакций с version storage/mssql он же UNDO/oracle это сильно.


Ты ещё скажи, что у UFS2 нет журнала, поэтому она сливает Ext4 (последняя даже снапшотить не умеет).

Ты слил, брюнетистый. Пользуйся дальше MySQL, у которой поддержка транзакций вкорячивается левым костылём — GPL такая GPL.

iZEN ★★★★★
()

всем почитателям firebird выше, посвящается:

буквально вчера пришло письмо «У нас есть купленное коробочное ПО для ..skipped..
Нас не устраивает скорость работы конечного приложения (в основном проблемы с отчетами).

Клиентское приложение написано на Делфи, код, конечно закрыт.
Число одновременно работающих пользователей от 10 до 15.
База данных построена на СУБД FireBird 1.5.
Размен файла базы данных 2.11 Гб
В базе хранятся: объемные картинки, данные,
Сервер Intel Xeon E5504 2Gh, 6 Gb RAM, RAID 1 SCSI Windows server 2003
Help!»

т.ч. нефиг тут меряться. все зависит от качества серого вещества, которое пользуется той или иной СУБД

k0l0b0k ★★
()

В firebird вакуум так и не реализовали? Нужно останавливать работу, дампать базу в файл, а потом ресторить из него?

AngryElf ★★★★★
()
Ответ на: комментарий от iZEN

Нет, по-твоему, приложение должно само раскидывать свои процессы/потоки по ядрам процессора вместо операционки? Может ещё задавать приоритет? Ты не болен случайно?


лапоть, именно этим и занимается любая субд серьезней фокспро, и собственно именно это и есть мечта девелоперов ФБ (судя по пятилетней задержки уже несбыточная) и основная фишка версии 3.0
в роадмепе она значиться так: Scalable (SMP/multi-core friendly) engine with the shared page cache (SuperServer evolution)
когда это появиться можно будет сравнивать с mySQL который имел это и отладил как минимум в третей версии.

лог транзакций опять есть у любой субд серьезней фокспро, с его помощью решается тьма задач от репликации не насилующей субд до отложенной записи в датафайл (это к вопросу тормознутости ФБ на фоне любой другой субд), ну и конечно возможность уносить логи транзакций обеспечивая возможность откатить назад или восстановить близко к моменту сбоя.

anonymous
()
Ответ на: комментарий от voodix

сам-то понял что сказал? Про этот «мегабаг» не слышал и писать на стандартом SQl-99 запросы в приложениях мне почему-то не мешает...


товарищ совсем с марса ? ты в курсе что проделает эта чудо субд на такие SQL-99 ?
delete from test where test.ID in (select id from test GROUP BY id HAVING count(id)>1);
update table set a=5, b=a ;
insert into MyTable select * from MyTable;

Начнем с того, что у FB есть оптимизатор.


лучше начать с того что он не полноценный Cost Based ;)

мноверсионность транзакций, которой у MySQL в помине нет и скорее не будет.


innodb имеет нормальный UNDO лог (терминами оракла) для версионного механизма за счет чего ему не нужно делать тормозной вакум

anonymous
()

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

boo32
()
Ответ на: комментарий от boo32

и да, к линуксу (и даже к опенсорсу) эта конференция имеет весьма посредственное отношение. видимо, виндузятники решили себя потешить мыслью, что их фаербёрд _может_ запускаться под линуксом. но практически это никому не нужно. а уж опенсорсность делфисты вообще не в состоянии понять, в большинстве своём.

boo32
()

А вот закроет Oracle сурсы Mysql --- и будет Firebird единственной альтернативой PostgeSQL. >_<

Чёрт.

sv75 ★★★★★
()
Ответ на: комментарий от voodix

> Я так понимаю «выстрелить себе в ногу» тебе не составляет труда...

Эти примеры больше похожи на «откусить себя яйца».

sv75 ★★★★★
()
Ответ на: комментарий от boo32

>и да, к линуксу (и даже к опенсорсу) эта конференция имеет весьма посредственное отношение. видимо, виндузятники решили себя потешить мыслью, что их фаербёрд _может_ запускаться под линуксом

У нас не только запускается под линукс, но и работает под ним непрерывано (практически - с разовым переездом на другой сервер) без малого 10 лет. При этом оперируя с пол-сотни баз по 2-5 ГБ базами, и обрабатывая огромное число данных. Отлично справляется со сложными запросами с огромным кол-вом данных.

Непонятно, почему его незаслуженно недооценивают.

voodix
()
Ответ на: комментарий от voodix

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

boo32
()
Ответ на: комментарий от voodix

Я так понимаю «выстрелить себе в ногу» тебе не составляет труда...


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

anonymous
()
Ответ на: комментарий от anonymous

> После открытия кода и переименования в Firebird контингент кодеров работающих с этой базой по-моему не изменился.

Ты мягко говоря неправ. Это если очень мягко говоря. ;)

Сама база вроде ничего, но конференция будет состоять из 99% виндузятников (Microsoft Live Meeting же).

И опять. Думается очно там присутствовать будут всякие люди. А в инете... Ну кто ж виноват, что линух до сих пор не разродился нормальным софтом для проведения видеоконференций.

anonymous
()
Ответ на: комментарий от anonymous

> у ФБ есть две архитектуры суперсервер и класик

Брехня-я-я-я... :)

anonymous
()
Ответ на: комментарий от anonymous

Опаньки, Йошка приперся. На скуль.ру регулярно в какашку закатывают, так ты сюда слинял? Вдолбись, убогое, - половина из того, что ты воображаешь о файрберде - информация 5-10 летней давности, а вторая половина - твои личные проблемы, которые не стоит выпячивять на всеобщее обозрение. И да - лучше бы ты таки любился со своим ораклом и не смущал сообщество.

anonymous
()
Ответ на: комментарий от AngryElf

> В firebird вакуум так и не реализовали?

Мосье случайно не родственник Петросяна? В firebird с рождения есть автоматическая сборка мусора. Автовакуума в те времена еще даже в виде сперматозоида не существовало.

anonymous
()
Ответ на: комментарий от anonymous

> это примеры всего лишь мизерной части частных случаев приключающихся у этой «особенной» во всех смыслах субд. реально они демонстрируют убогость

Если это мизерная часть примеров «мегабагов», то мне наверно повезло, что за много лет я так и не наткнулся на них. Откуда такая навязчивая нелюбовь к FB. Ну да ладно: не нравится - значить что-то личное. По мне - СУБД отличная. Ни разу не подвела и ничего такого, что бы стесняло «ограниченными возможностями» - нет, ни разу... Ну только разве бедность синтаксиса хранимых процедур - но это и плюсЪ.

voodix
()
Ответ на: комментарий от no-dashi

>ЗАПОМНИ, НЕДОЛРОСЛЬ - ТРОЛЛИТЬ ТУТ МОЖНО ТОЛЬКО СО ВТОРОЙ ЗВЕЗДЫ!!!

а тупить - с третьей

black7
()
Ответ на: комментарий от iZEN

>> 2. лог транзакций

Не нужен. Сама СУБД Firebird имеет версионную


бгг, а мне ещё с жалобы сильви за «*здунов» пост покоцали. узрите же народ

black7
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.