DBISAM..?

← →
Type (2009-08-10 16:44) [0]

Что вы думаете относительно использования DBISAM в крупных коммерческих проектах?

← →
KilkennyCat © (2009-08-10 16:51) [1]

ничего не думаю.

← →
Медвежонок Пятачок © (2009-08-10 17:05) [2]

зачем же насиловать будущих покупателей установкой экзотики?

← →
Palladin © (2009-08-10 17:05) [3]

а что такое крупный коммерческий проект... с какой стороны он крупный и с какой коммерческий?

← →
Palladin © (2009-08-10 17:06) [4]

а особенно важно, с какой стороны он вообще проект :)

← →
Jeer © (2009-08-10 17:06) [5]

Пользовался еще в прошлом веке, правда файл-серверной версией.
Наилучшие впечатления.
К слову сказать, один из проектов, разработанный в 2001 г до сих пор работает, причем без какого-либо сопровождения.

← →
Медвежонок Пятачок © (2009-08-10 17:35) [6]

Ну для прошлого века возможно это чудо и прокатило бы на ура.

← →
Холивар (2009-08-10 18:47) [7]

> Type (10.08.09 16:44)
>
> Что вы думаете относительно использования DBISAM в крупных
> коммерческих проектах?

Оно и в мелких не очень. Пробовал применить(давно) - в результате часть кода пришлось переводить для работы через Access.

Рекомендую сразу брать FB embeded для локальной БД.

← →
Jeer © (2009-08-10 18:47) [8]

Это не "чудо", а весьма распространенная на Западе СУБД для относительно небольших баз. Впрочем, особых ограничений на объем у нее нет.

Достаточно сказать, что среди своего класса в начале 2000-х г. занимала первые места.

← →
Jeer © (2009-08-10 18:50) [9]

> Рекомендую сразу брать FB embeded для локальной БД.

В посте автора ни слова не было сказано о локальной СУБД.

← →
Jeer © (2009-08-10 18:53) [10]

Дифирамбы DBISAM :)
http://www.compress.ru/article.aspx?id=11604&iid=454

← →
Холивар (2009-08-10 18:54) [11]

> Jeer © (10.08.09 18:50) [9]
>
> > Рекомендую сразу брать FB embeded для локальной БД.
>
> В посте автора ни слова не было сказано о локальной СУБД.

Не если для клиент-серверной то тогда точно или FB, или PostgreSQL. Две базы которые уже можно как-то сравнивать с такими гигантами как MSSql и Oracle.

Для той и другой есть нативные клиенты для Delphi.

← →
Медвежонок Пятачок © (2009-08-11 09:13) [12]

Достаточно сказать, что среди своего класса в начале 2000-х г. занимала первые места.

Я и говорю, что для прошлого века сойдет.

← →
Jeer © (2009-08-11 15:35) [13]

> Две базы которые уже можно как-то сравнивать с такими гигантами
> как MSSql и Oracle.

Не всегда гигантизм, есть лучшее при наличии хорошего.

> Я и говорю, что для прошлого века сойдет.

Надеюсь, понимаешь, что ты не Истина в последней инстанции.

← →
Медвежонок Пятачок © (2009-08-11 17:37) [14]

то что в 2001 была написана система на этом чуде и работает до сих пор - тоже не истина и не в инстанции.

я в 2000 написал систему на парадоксе. до сих пор работает по всей РФ.
и чего?

← →
Jeer © (2009-08-11 18:02) [15]

Т.е. сегодня надо обязательно на ORACLE, иначе не круто смотришься ?

Глупости все это.
Делать надо на том, на чем быстрее сделаешь, эффективнее будет работать для конкретной задачи, цена покупки или бесплатный сыр и т.п.

DBISAM интересна и сегодня, как "легкая" СУБД, как вариант - встраиваемая в приложение, есть возможность работы на CD-ROM, на Win CE для мобильных устройств и др. интересные особенности.

← →
Медвежонок Пятачок © (2009-08-11 18:07) [16]

Это может быть и верно, но только отчасти.
Я имею ввиду ставить себе задачу "чтобы побыстрее написать"
Написал ты быстро, замечательно.
Затем у пользователей возникают вопросы а как бы повзаимодействовать с бд в другом ключе (имеют право между прочим, так как данные то в БД - их собственные)

И вот дальше начинается рокенрол.
А где оле-дб провайдер, а где одбц драйвер, а где еще что-то.
А где втроенные средства интеграции с веб и другими системами.

И вопросов этих много.

← →
Медвежонок Пятачок © (2009-08-11 18:13) [17]

... Тем более что в вопросе речь идет о "больших коммерческих проектах".

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

← →
Дуб © (2009-08-11 18:18) [18]

> Данные его БД должны быть доступны с разных платформ и в
> разных средах разработки. И чем меньше с этим геморроя у
> пользователей, тем лучше и им и самому разработчику.

перпекндикулярно, но есл деньги есть, то иногда параллельно.

← →
Jeer © (2009-08-11 18:22) [19]

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

Т.е. просили сначала сделать шлюпку, а в процессе "гребли" захотели иметь "Куин Мэри" ?
Это проблема Заказчика и для ограничения таких порывов служит как-раз грамотное ТЗ.

← →
Jeer © (2009-08-11 18:27) [20]

P.S.
Еще одной особенностью DBISAM ( разумеется не у нее одной есть такое "чудо") является возможность шифрации базы, что опять таки зависит от задач.
При наличии исходников DBISAM ничто не мешает переопределить алгоритм шифрации и далее, данные становяться недоступными иначе чем через разработанный софт.
Т.е. со стороны невозможна их модификация.
Если кто скажет что все админы белые и пушистые, я не поверю.
Это к вопросу о несанкционированном съеме данных.

← →
Anatoly Podgoretsky © (2009-08-11 19:22) [21]

> Медвежонок Пятачок (11.08.2009 18:13:17) [17]

Тогда по сути, на Виндоус, этот набор ограничен Access 2003/2007, Oracle, MS SQL - именно этот набор ограничен в качестве в качестве базового ADO и частично ODBC, все остальное требует дополнительных средств и определенные трудности.

← →
Anatoly Podgoretsky © (2009-08-11 19:24) [22]

> Jeer (11.08.2009 18:22:19) [19]

Для ограничения таких порывов требуется не ТЗ, а грамотные экономические отношения, а ТЗ это всего лишь инструмент поддержки.

← →
Медвежонок Пятачок © (2009-08-11 19:42) [23]

Тогда по сути, на Виндоус, этот набор ограничен Access 2003/2007, Oracle, MS SQL

Расскажу как я сейчас себе это представляю.
Если я пишу корпоративный софт, который работает только внутри сети предприятия, то выбора особенно и нет. Использую что есть + выбираю компоненты доступа по вкусу.

Если же софт работет за пределами офиса (у наших клиентов), то я теперь никогда не лезу в их монастырь со своим уставом.
Если у клиента уже есть оракл - ему будет выдано ПО работающее с ораклом. Если есть mssql - то он. Если ничего нет, то либо FB либо acccess.

То есть проблемы выбора дбмс у меня нет вообще.

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

реальный пример:
У меня были три версии: mssql на ado, fb на fib и акцесс тоже на адо и джет.

пришла пятница, мне стало грустно и я подумал, что не хватает версии под оракл. Через полтора часа она у меня была.
В эти полтора часа был поставлен сам оракл, в делфи был установлен ODAC, отредактированы ddl скрипты, создан новый dpr + новый наследник модуля данных. В завершении процесса переопределены 15-20 виртуальных методов модуля и сделан билд.

И все.

И появилась версия под оракл на одак.

← →
Anatoly Podgoretsky © (2009-08-11 20:13) [24]

> Медвежонок Пятачок (11.08.2009 19:42:23) [23]

В вопросе было не про твой софт, он может на чем угодно работать, а про доступ стороннего софта к твоим базам данных, при том везде, для платформы Виндоус я указал минимум. А Дельфи пока только на ней работает и минимальный обязательный доступ ограничен приведеным списком, все остальное требует дополнительной установки ПО. Поэтому в списке нет IB/FB и другой экзотики.

Подобные проблемы с доступом к посторонним БД мне пришлось решать в начале года, БД была на Акцессе, пусть и без описания, в итоге задачу решил за один рабочий день. Надо было состыковать пропускную систему (Акцесс) с базой Персонала (MS SQL) и организация дополнительных отчетов.
Проблем не было, несколько минут на состыковку доступа (бросить на форму ADOConnetion и настроить), остальное изучение таблиц. Установки дополнительного ПО и изучениея не потребовало, в отличии от банковской системе на FB - хорошо, что я еще помню старый ИБ, но могло бы быть и иначе.

← →
Медвежонок Пятачок © (2009-08-11 20:17) [25]

похоже мы об одном и том же.

крупный коммерческий проект не должен быть вещью в себе с пулеметами по периметру.

людям может потребоваться доступ к данным (не обязательно из винды и не обязательно они при этом владеют delphi)

← →
Медвежонок Пятачок © (2009-08-11 20:25) [26]

еще одна реальна история про реального клиента.

прихожу на днях в одно ООО. Вижу Пентиум-3, 512 RAM и две тетушки.
Смотрю на зоопарк обязательного для них софта.
- что-то налоговое на яффиле
- что-то по учету алкоголя на mssql
- что-то пенсионное еще на чем-то.
- чья-то поделка для зарплаты на дибейсе.

тут нарисовываетесь вы и говорите: знаете, я вот когда-то попробовал dbisam, и мне жутко понравилось. Пусть у вас в системе появится еще один процесс (сервер dbisam). Ибо это нормально я считаю.

← →
Холивар (2009-08-11 21:09) [27]

> Медвежонок Пятачок © (11.08.09 20:25) [26]

dbisam не процесс - он внутри Exe стартует(как и FB Embeded).

← →
Jeer © (2009-08-12 09:36) [28]

> Медвежонок Пятачок © (11.08.09 20:25) [26]
> еще одна реальна история про реального клиента.

Не надо притягивать за уши еще одного реального клиента - уши оторвутся.
Изначально вопрос был не об этом.
Поэтому мой ответ на тот вопрос: "Да, можно использовать DBISAM для коммерческих проектов".
Что такое "крупный" - не знаю.
Какие еще требования по кросс-платформенности, перносимости, доступу к базам извне софта - это все определяется по мере изучения ситуации у Заказчика и его требований, если они есть.

Ровно также могу сказать, что есть у меня работающий проект, которому вообще пофигу, какой сервер баз данных. Может работать с любым, поддерживающим SQL-92 и имеющем ODBC-драйвер.
Но это частные случаи, определенные спецификой задач.
Закладываться каждый раз на такую кросс-платформенность я бы не стал.

Ну так и я сказал что и парадокс тоже можно использовать в крупных коммерческих проектах.
У меня вон используется и проблем нет. Особенно после того, как у пользователей исчезли сетевые шары на win9x
Все работает как часы.

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

Ну и зря.
Я заложился и жить стало легче.
Причем это совсем не тот коленкор когда у тебя адо+одбс+отказ от фирменных фич конкретного сервера.

я например пользуюсь ими в полном объеме какой мне требуется. И в то же время на сопровождение отнимает почти столько же времени, если бы был один проект для конкретного сервера и для конкретной библиотеки доступа.
доп. накладные расходы времени я оцениваю как 1-2% сверху.

> Медвежонок Пятачок © (12.08.09 09:58) [30]

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

А закладывать реализацию бизнес-логики только на клиента - это ничем не оправданное ограничение.

С бизнес логикой как раз все ок.
Она у меня живет в слое, который ничего не знает ни о сервере ни о компонентах доступа.

Если я провожу модификацию ПО, я открываю любой проект, делаю в нем изменения и отлаживаю. Затем поочередно открываю остальные dpr и делаю билд для остальных платформ и библиотек.

Все алгоритмы и логика общие в одних и тех же модулях.
При этом в моем распоряжении остаются все спец фичи конкретных серверов.

более того - все интерфейсные формы (справочники, редактирование, документы) - они тоже спроектированы в нейтральном слое, ничего не знающем про конкретный сервер и про компоненты доступа.

Это значит, что она ( бизнес-логика ) у тебя реализуется не на сервере.
А где именно, уже не так важно.

ей ничто не мешает жить на сервере и она там живет кстати.

я же говорю, что у меня совсем не та ситуация, когда для универсальности используют только стандарт sql и одбс драйвер.

Посмотрел описание продуктов и убедился, что ребята из Elevate Software время зря не теряли с прошлого века и предлагают сегодня два продукта
- DBISAM с которой я знаком с 1998 г
- ElevateDB ( флагманский продукт )

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

ElevateDB поддерживает SQL-2003, а DBISAM - SQL-92.

ElavateDB
http://www.elevatesoft.com/prodinfo?action=view&product=edb&no=1

DBISAM
http://www.elevatesoft.com/prodinfo?action=view&product=dbisam&no=1

Можно. И на парадоксе можно.

Вопрос скорее в том, нужно ли.

Вот это более интересно
http://www.elevatesoft.com/prodinfo?action=view&product=dbisam&no=7

Fail-safe transactions and referential integrity are not currently supported in DBISAM.

поделка. колхозная.

> Вот это более интересно

Это старый продукт. По большому счету он не ушел далеко от файл-серверного режима.

DBISAM..? Найти похожие ветки