Прочел тут топик, где заспорили о том нужно ли развивать FoxPro или MS лучше забить, и в который раз задумался: допустим хочу я написать приложение, для задач которого очень удобно часть данных хранить в некоей БД. В таком варианте у меня появляются дополнительные удобства (и проблемы ), как то использование SQL для "массированной" обработки данных и пр. Много говорить не буду, т.к. все в этой теме выгоды использования БД лучше меня понимают.
Но за свою недолгую жизнь я неявно сталкивался с такой ситуацией: программа такая-то некоей организации нужна, но вот заставлять ее покупать MS-SQL или Oracle не имеет смысла. Сразу по нескольким причинам: файлы с данными никогда не будут зраниться централизованно на сервере, каждый экземпляр программы запускается для эксклюзивного редактирования какого-то проекта (файла данных, группы файлов, автономного набора данных), нет возможности воспользоваться услугами админа БД для поддержания всей информации, стоимость сервера БД намного превышает стоимость создания самой программы, клиенты должны иметь возможность "скопировать на дискету и отдать коллеге". Если причин мало, то я могу привести еще с конкретными примерами.

Так вот какая ситуация получается.
С Борландом все понятно: есть BDE, установленный в системе, и все обращения к файлам осуществляются с его помощью.
У MS только FoxPro создает приложения, работающие "автономно". Несколько мойх файлов + пара dll для работы с фалами FoxPro. Все остальные варинты создания клиента от MS,будут требовать наличия хотя бы Access, который тоже денег стоит.

Если мой вопрос звучит тупо, то please сразу шапками не закидывайте. Просто я никогда серезно над этой проблемой раньше не задумывался, а тот же BDE по сути тоже сервер и я своего клиента не смогу запустить с дискеты без предварительной установки BDE в систему. Про DOS я вообще молчу.

P.S. Хочется свободы в выборе, а не монополию от того же борланда на BDE.

Это сообщение отредактировал(а) DENNN - 20.4.2003, 13:07

А в чём конкретно помочь? Написать автономную БД ?

Для начала необходимо определиться в своих требованиях к БД. Как то -
1) Размер и сложность разрабатываемой базы.
2) Необходимое быстродействие.
3) Необходимость (или желательность) возможности многопользовательского доступа
4) Имеющееся в наличие аппаратное/программное обеспечение
5) Уровень квалификации системного администратора.
Отсутствие такого бойца - явный признак несерьезного отношения в данной организации к надежности и эффективности работы ПО и потенциальная причина последующих мелких проблем и глобальных катастроф.

Во вторую очередь, необходимо учесть:
1) Отношенние к лицензионному ПО (или его наличие)
2) Имеющиеся в наличии программные наработки

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


P.S. Что же касается Delphi и BDE, то это не единственно возможная комбинация. Кроме этого, Delphi может использовать:
1) ActiveX Data Objects (ADO) - Начиная с Delphi 5
2) InterBase Express (IBX) - Начиная с Delphi 5
3) dbExpress - Начиная с Delphi 6
4) Excel (по крайней мере файлы при его отсутствии)
5) Собственные компоненты доступа к БД
6) Компоненты доступа к БД сторонних разработчиков
......

Цитата

Отсутствие такого бойца - явный признак несерьезного отношения в данной организации к надежности и эффективности работы ПО и потенциальная причина последующих мелких проблем и глобальных катастроф

Я же пояснил, что для ряда задач сервер БД, а значит и админ в сущности не требуются.
Пример: есть упрощенная ГИС-система. В ее задачи входит примитывные графические операции по редактированию векторной графики и атрибутов объектов. Цель использования данной програмы - обработка результатов измерений и перекидывание данных дальше в другие продукты. Причем в таблицах хранятся не только атрибуты но и координаты векторных данных. Использовать средства SQL для задач, поиска оптимизации и удаления данных для такой задачи очень удобно, а вот привязка к серверу или некоторым компонентам совсем лишняя. Прога написана на FoxPro то ли 5 толи 6 версии. Выглядит все как папка, в которой 15~20 файлов. Можно скопировать эту папку и запустить на любом компе, где винда не ниже 95.
Это один из тех примеров о котором я говорил. Речь не идет о корпорации, в которой админ раз в месяц покупает винт 120 Гб.
Поймите, для большого ряда задач при стандартном подходе получается неоправданное усложнение системы.
Что крутого, если бы в моем примере создали прогу с дистрибутивом на 300 мегов, пытающейся установить на ноутбук P-100Mhz MDAC 2.6, IE 6.0 и SQL-сервер? Я таким ноутбуком смогу только сидя в офисе пользоваться.

Это сообщение отредактировал(а) DENNN - 20.4.2003, 20:21

Цитата

А в чём конкретно помочь? Написать автономную БД ?

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

1) Сервер БД - это такая же программа как и Ваша прикладная. За любым программным обеспечением должен быть присмотр. Не обязательно это должен быть отдельный сотрудник/(крупный специалист)- часто вполне достаточно квалифицированного пользователя.
"Хорошая" программа теоретически не должна привлекать к себе дополнительного внимания, но любая программа существует не сама по себе, а во взаимодействии с операционной системой/железом/другими програмами. И изменения в их работе вполне могут привести к последствиям в работе Вашей "хорошей" программы. Это общеизвестно и многократно доказано на практике. Поэтому, говорить что программе на Fox'е не нужно сопровождение - не остроумно.

2) Использование сервера БД часто имеет смысл даже для простых приложений. Поскольку, серверные БД, обычно, по функциональности и параметрам на порядок лучше локальных баз. А по ресурсам некоторые из них (Например, InterBase или Firebird) весьма не требовательные. В минимальной установке хотят не более 10 Мб и к оперативке/процессору выдвигаю тоже весьма померные требования.

Кроме того, сейчас в эпоху повального лицензирования ПО многие вынуждены сползать с Windows на Linux/FreeBSD. А FoxPro под ними не идет...

Использование же связки Delphi+InterBase(Firebird) под Win практически без изменений переносится на Kylix+InterBase(Firebird) под Linux/FreeBSD.

Может народ в курсе - появился FireBird Embedded - бесплятный сервр, НЕ ТРЕБУЮЩИЙ установки и "занимает" 1 dll +1 msg. Полноценный SQL Server для локального использования. Есть такой-же Yaffil (Питерский InterBase), но он платный 7$ за копию - чем не вариант. На сегодняшний день я альтернатив не вижу. И в случае расширения - ставишь полноценный IB/FB/Yaffil и работаешь в сети без вопросов.

Цитата

Сервер БД - это такая же программа как и Ваша прикладная

Так и я о том же! пусть он будет встроен в мою прогу жестко и плевать мне что там в системе происходит или установлено.

Цитата

За любым программным обеспечением должен быть присмотр

За стандартным проводником виндов у тебя каой админ присматривает?
Присмотр нужен за теми данными, которые храняться централизовано и имеют какой-то мало-мальский публичный доступ. Вспомним советские времена: когда собственность публичная, то все ей пользуются но никто ответственности не несет, а значит никто и в порядке не поддерживает.
Вернемся к теме. В описанном выше примере никакой админ НЕ НУЖЕН. Так же как не нужен админ по документам ворда или таблицам экселя. Если вы внимательно вдумаетесь о чем я пишу и постараетесь не мыслить стереотипами "БД=клиент+сервер => два компонента".
Это проблема всех современных технологий: для того чтоб разбить орех, покапают молоток с поддержкой круглых кнопок, иконок TrueColor и виндос медиа плеер встроенным в систему более надежно чем даже IE.

Цитата

"Хорошая" программа теоретически не должна привлекать к себе дополнительного внимания, но любая программа существует не сама по себе, а во взаимодействии с операционной системой/железом/другими програмами. И изменения в их работе вполне могут привести к последствиям в работе Вашей "хорошей" программы. Это общеизвестно и многократно доказано на практике.

Я конечно могу быть не прав, но все это пустые и ничем не обоснованные рассуждения. Такие логические построения на форруме можно расписать по любой теме. И будет как у Йона Тихого: "После решения уравнения получилось математически верное равенство 0=0. ..... Следовательно не существует вообще ничего, а значит и самой проблемы."

Цитата

Я конечно могу быть не прав, но все это пустые и ничем не обоснованные рассуждения...

Вообще то эти рассуждения основаны как на моем опыте профессиональной работы с компьютерами (в общей сложности более 10 лет), так и на опыте уважаемых специалистов.
А насчет присмотра за проводником и др., то в любой уважающей себя фирме, даже малочисленной, есть по крайней мере приходящий специалист, который снимает проблемы. А там где этого нет - нет и нормальной работы с компами. Приходилось сталкиваться с такими чудесами - то комп работает только в режиме защиты от сбоев, то документы хранят в "корзинке" и находят это очень удобным...

Цитата

"БД=клиент+сервер => два компонента". Это проблема всех современных технологий

На самом деле, это не проблема а достоинство. Оставим в стороне всю мощь современных SQL серверов. И представим себе, что у Вас несколько программ для БД(пусть даже локального характера), Например 3.
Сравним
1) Ваш вариант
3 программы + DLL+ 3 каталога с кучей DBF, CDX, FPT файлов...

2) Вариант InterBase/FireBird
3 программы + 1 сервер + 3 (а можно и 1) файла!!!

И что лучше?
А если программ будет еще больше?

Это сообщение отредактировал(а) remax - 22.4.2003, 18:50

Уважаемый remax! прочтите внимательно мое самое первое сообщение.
Я не называю технологию клиент+сервер неверной или абсолютным злом. Я объяснил, что иногда для решения ряда задач очень удобно иметь встроенные компоненты сервера в свое приложение. Особенно в таких случаях, когда к данным нет публичного доступа. И от сервера мне необходимо только выполнение комманд SQL, а о сохранности данных в такой конфигурации я позабочусь, я Вас уверяю.
Случай из моей практики: есть данные формата dbf(или иного сейчас вопрос не в этом), накопленные в результате работы большой проги. Пишется конвертер данных в другой формат. Так для того чтоб просто считать все данные необходимо наличие в сервера. Что я буду делать, если эти данные я скачал по мобильнику на свой ноутбук стоя на городском перекрстке. Как мне воспользоваться конвертером? Не говоря уже о случае (тоже описанном мной), когда необходимо из обсуждаемой проги скопировать данные и переслать по почте в другой город. Согласитесь что для пользователя гораздо проще научить копировать файлы на диск, чем делать выборку из БД и осуществлять резервное архивирование или что-то еще.

Я пишу о том, что для проги размеров в 300 килобайт SQl-сервер, требующий для своей работы win2000Server и стоящий изрядные деньги, смотрится неоправданной роскошью. Я конечно утрирую. Но вопрос этот радился не из головы или моего праздно любопытства.

Цитата

Я пишу о том, что для проги размеров в 300 килобайт SQl-сервер, требующий для своей работы win2000Server и стоящий изрядные деньги, смотрится неоправданной роскошью

Я прочитал несколько выше такое сообщение

Guest_IgorK

Цитата

Может народ в курсе - появился FireBird Embedded - бесплятный сервр, НЕ ТРЕБУЮЩИЙ установки и "занимает" 1 dll +1 msg. Полноценный SQL Server для локального использования

Я не очень понял идею и проблему - если не нужен дорогой и мощный SQL - используем дешевый.
Если нужны локальная база - используем старый добрый DBF или вариант типа TClientDataSet из Delphi. Также сегодня в .NET есть подобный механизм. Причем данные можно хранить прямо в XML. Что, кстати и продукты Borland умеют.

Кстати, сам принимал участие в создании проекта на FoxPro, который умел работать как с локальными DBF, так и с MS SQL, ORACLE и SQLBase.
Проект не был сложным по запросам, но тем не менее факт такой есть.

Кроме этого уже много лет отрабатывается многозвенная архитектура, которая позволяет вообще свести зависимость от типа хранилища данных к минимуму и использовать только самыt наипростейшие конструкции SQL.

Цитата

Я не очень понял идею и проблему - если не нужен дорогой и мощный SQL - используем дешевый.

Проблема в том что если использовать для локальных прог один формат, а для серверных другой, то нужно 2 разные проги, которые будут работать с разными форматами или писать одну, но закладываться на возможность использования на разных форматах. Firebird|Yaffil Personal имеет ОДИНАКОВЫЙ формат базы, ОДИНАКОВЫЕ возможности - тригера, хран. проц., UDF и т.п. - все то, что имеет InterBase и его клоны. Согласитесь, что ни XML ни TClientDataSet не обладают такими возможностями. А локальные программы имеют свойство разрастаться до сетевых, и в этом случае начинается геморой. В случае с Yaffil Personal (кстати уже бесплатный!) нужно только будет поставить сервер и все!