форматы баз данных (dbf, db, mdb,...)

← →
AntonVS © (2004-04-26 14:25) [0]

хочу поднять пару-тройку вопросов (может быть даже - филосовских)

какой из форматов больше подходит для реализации многопользовательской СУБД, т.е. сетевой СУБД?

какими средствами лучше всего поцеплятся к ним (BDE, ADO, ....)?

как с транзакциями дружат?

← →
evvcom © (2004-04-26 14:30) [1]

dbf, db - локальные СУБД, с mdb не работал никогда, вообще не знаю, что это. db хоть и работает в сети, но очень паршиво. Лучше выбрать какой-нибудь серверочек (в зависимости от полноты кармана, толщины кошелька или нравственных устоев могут быть различные варианты)

← →
Vlad © (2004-04-26 14:47) [2]

> evvcom © (26.04.04 14:30) [1]

> mdb не работал никогда, вообще не знаю

mdb-Access

> AntonVS © (26.04.04 14:25)

Почему такой странный выбор ?
Чем клиент-серверные СУБД не угодили ?

← →
AntonVS © (2004-04-26 14:55) [3]

mdb - это Access

вообще, подозреваю, что для реализации сетевой СУБД под виндой - это самый удачный вариант....

ADO - дружит с Access-ом.
к dbf - только через ODBC, если пользовать ADO
BDE - умеет сам, но бывает глучит он.

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

расскажите, что-нибудь про Access плохое...

← →
AntonVS © (2004-04-26 15:00) [4]

Vlad, всю жизнь так делал - локальная - так локальная база(в данном случае - старый добрый dbf....)

больше одного пользователя - SQL....

попалось мне пара вредных заказчиков, не хотят они SQL-серваки юзать....

так что только - сетевая СУБД

← →
HSolo © (2004-04-26 15:05) [5]

> попалось мне пара вредных заказчиков, не хотят они SQL-серваки юзать

Они это как-то мотивируют, или просто "а потому что!" ?
А других заказчиков, не вредных, так мало, что их можно не принимать в расчет?
А что такое, в Вашем понимании, "сетевая СУБД"?

← →
Romkin © (2004-04-26 15:07) [6]

AntonVS © (26.04.04 15:00) [4]
>попалось мне пара вредных заказчиков, не хотят они SQL-серваки юзать....
Хе-хе Yaffil Personal им :)) Когда захотят сервак - установишь, и только одно слово добавить

← →
bushmen © (2004-04-26 15:07) [7]

>так что только - сетевая СУБД

А SQL серваки - это не сетевые СУБД? Да и что означает "не хотят юзать"? Им нужен работающий продукт или "лишь бы как"?

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

У меня 10 пользователей одновременно работают с Paradox-базой. Ни одной проблемы еще не было

← →
Vlad © (2004-04-26 15:08) [8]

> Romkin © (26.04.04 15:07) [6]

Дык Yaffil Personal однопользовательский.
Толку от него в сети, если только один пользователь может одновременно его юзать ?

← →
AntonVS © (2004-04-26 15:20) [9]

> А что такое, в Вашем понимании, "сетевая СУБД"?

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

> У меня 10 пользователей одновременно работают с Paradox-базой. Ни одной проблемы еще не было

я так понимаю, BDE пользуешь. и небыло глюков?
а с индексами, с блокировками? с блокировками Paradox, если не ошибаюсь не дружит. базы толстые?

>

← →
DevelS (2004-04-26 15:21) [10]

BTrieve 6.5

← →
Serginio666 (2004-04-26 16:18) [11]

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

← →
Anatoly Podgoretsky © (2004-04-26 16:32) [12]

AntonVS © (26.04.04 15:20) [9]
Третья градация лишняя, SQL клиент-серверная может быть локальной или сетевой.

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

← →
Sergey13 © (2004-04-27 08:50) [13]

2AntonVS © (26.04.04 14:25)
>хочу поднять пару-тройку вопросов (может быть даже - филосовских)
О!!! Это я люблю. 8-)

>какой из форматов больше подходит для реализации многопользовательской СУБД, т.е. сетевой СУБД?
Ни один не подходит. Хотя работать может любой. Вообще формат файла никак не касается разработчика БД.

>какими средствами лучше всего поцеплятся к ним (BDE, ADO, ....)?Лучше вообще без этого, напрямую.

>как с транзакциями дружат?
С транзакциями дружат/недружат не форматы файлов, а программы обслуживания этих файлов, т.е. сервера БД и/или пользовательские проги. Нет сервера или плохая кл.прога ... ну ты понял...

>больше одного пользователя - SQL....
попалось мне пара вредных заказчиков, не хотят они SQL-серваки юзать....
А что ты понимаешь под "SQL-серваками"? MS SQL Server может быть? Тогда я прекрасно понимаю твоих заказчиков и согласен с ними. Если например FB, то вряд ли непродвинутый заказчик вообще заметит его присутствие на компе.

← →
sniknik © (2004-04-27 09:05) [14]

> Если например FB, то вряд ли непродвинутый заказчик вообще заметит его присутствие на компе.
если бы MS SQL Server не офишировал себя так явно то его тоже ирудно было бы заметить.
убери иконки в меню, менеджер из автостарта (в общем все кроме сервисов) и покажи непродвинутому заказчику, вряд ли найдет.

← →
AntonVS © (2004-04-27 09:13) [15]

> Если например FB, то вряд ли непродвинутый заказчик вообще заметит его присутствие на компе.

не пойдет все это

хотят, чтоб база была на файл-сервере.
файл-сервер - на "Samba"

FB под Linux админ боится ставить и админить....

← →
roottim (2004-04-27 09:28) [16]

на 2-3 пользовател можно и не на линукс(хотя странная стратегия компании использовать линукс как файл-сервер для баз), а на обычный Win2k рабочюю станцию... FB весит мало... незаметят, остальные подключатся к нему...

← →
Sergey13 © (2004-04-27 09:30) [17]

2sniknik © (27.04.04 09:05) [14]
Я имел в виду не то. MS SQL денюжку стоит, и не малую. Да и ресурсы, я полагаю, любит (MS все таки 8-). Для простенького склада какого нить - не самый лучший выбор. ИМХО. С этой точки зрения я и понимаю заказчиков. Многие, также, стали заботиться и о лицензионной чистоте.

2AntonVS © (27.04.04 09:13) [15]
>хотят, чтоб база была на файл-сервере.
>файл-сервер - на "Samba"
А сам сервер на Кипре?

>FB под Linux админ боится ставить и админить....
8-))))))))))))))))))

← →
AntonVS © (2004-04-27 09:31) [18]

>хотя странная стратегия компании использовать линукс как файл-сервер для баз

не спорю....

вообще, файл-сервер на "Samba" - не самое удачное решение

← →
Anatoly Podgoretsky © (2004-04-27 09:42) [19]

Sergey13 © (27.04.04 09:30) [17]
MS SQL бесплатен, конечно не надо ставить большой MS SQL

файл-сервер на "Samba" - не самое удачное решение не то слово

← →
Mentat (2004-04-27 09:46) [20]

Клиенто-сервер конечно рулит :-)
Но в принципе можно mdb нормально идет по сети (при очень малой базе и малом числе пользователей).

← →
Евкисий © (2004-04-27 09:49) [21]

Кстати, а чем в таком случае не устраивает MySQL и легкий, и бесплатный и мультиплатформенный...

← →
AntonVS © (2004-04-27 09:53) [22]

>Но в принципе можно mdb нормально идет по сети (при очень малой базе и малом числе пользователей).

Во...
уже ближе к делу....

Кто-нибудь, что-нибудь про mdb плохое может сказать?

← →
Sergey13 © (2004-04-27 10:03) [23]

2Mentat (27.04.04 09:46) [20]
>Но в принципе можно mdb нормально идет по сети (при очень малой базе и малом числе пользователей).
При этих условиях все идет, особенно если руки не совсем кривые. 8-)

← →
Rule © (2004-04-27 10:18) [24]

2bushmen © (26.04.04 15:07) [7]
//У меня 10 пользователей одновременно работают с Paradox-базой.
//Ни одной проблемы еще не было

Не верю, хоть убей. Сколько рабоаю с парадоксом столько он и опарвдывает свое название, сплошной парадокс, он годится только для одного пользователя и то только если в программе есть средства по ремонту ...

← →
Rule © (2004-04-27 10:23) [25]

советую Фаерберд поставить и много денег не надо и средства разработки нормальные, даже ИБИКс намного лучше работате чем БДЕ в данном случае, советую просто, если ты разработчик то должен убедить клиента в этом, так как тебе отвечать за стабильность работы продукти либо снять с себя эту ответственность елси они будут настаивать, вот так ...

← →
AntonVS © (2004-04-27 10:35) [26]

Rule, расскажи, если можно, подробней про глюки Paradox-а при сетевой реализации...

← →
Rule © (2004-04-27 10:44) [27]

AntonVS © (27.04.04 10:35) [26]
ох уже не помню но щас попробую,
значит помню очень часто при работе с блоб полями он ругался что не могу найти там какуюто запись потомучто поток не закрыт, лечится толко удалением этой записи, потом часто возникает ситуация что падают индексы, приходится переиндексировать таблицы (раза 2 в неделю при интенсивном использовании, проверено на практике), есть ещё клюк блокировки записей, которые почемуто блокируются и не снимают блокировку даже если к нему никто не обращается приэтом это происходит както спонтанно, ну и ещё пару интересный приколов связанных с блокировкой таблицы и противоречивости данных,
хочется скажать что не продумана эта БД под сетевое использование и из-за своей нестабильности и избегаю я её для локальныйх БД, тем более что в этих БД хранятся данный про деньги (поддерживаем одну систему написанную в 80-х или начале 90-х, собираемся переписывать бо больше не можем терять смены и деньги из-за глюков), вот так

← →
AntonVS © (2004-04-27 11:03) [28]

Rule, спасибо.

про Paradox, при сетевом ее пользовании, ранее слышал, что с блокировками не дружит и индексы падают. Сам же не пользовал...

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

← →
Курдль © (2004-04-27 11:10) [29]

> Кто-нибудь, что-нибудь про mdb плохое может сказать?

Если это и вправду Access, то ничего плохого не могу - никогда не приходило в голову использовать его, как БД :)

И для справки о серверах БД. Мы поставили оракл в одно очень большое мед. учреждение, где сисадмин - врач по совместительству. Комп, конечно, он включить может... :) Так что надо делать проги, чтобы они никаких спецов не требовали.

← →
Sergey13 © (2004-04-27 11:12) [30]

2AntonVS © (27.04.04 11:03) [28]
Такие отзывы ты получишь о любой настольной БД при использовании ее в многопользовательском режиме. Различные ухищрения могут несколько сгладить проблему, но совсем она не исчезнет. Индексы - это физическая целостность БД, а вот логическая целостность и непротиворечивость данных это совсем другое. Брось ты этот тупиковый подход. Ставь сервер.

← →
Rule © (2004-04-27 11:21) [31]

>Sergey13 © (27.04.04 11:12) [30]
согласен на все сто

>Курдль © (27.04.04 11:10) [29]

Вешчь оракл то хорошая, но вот стоит тоже прилично и иногда её использование в маленьгих проектах нецелесообразно, поэтому советую огненную птицу (жарптица или Firebird), много документации а вот использование Акцесс в качестве сетевой бд ну по моему вообще изврат, не для этого его придумали, для этого мелкософт придумал МССКЛ (в народе MSSQL) вот так, не делай с самого начала ошибку потом будешь плюватся

← →
Курдль © (2004-04-27 11:25) [32]

> Вешчь оракл то хорошая, но вот стоит тоже прилично и иногда
> её использование в маленьгих проектах нецелесообразно,

Да я о том, что мы давно отказались даже от "локальных" БД. Все делается, как минимум, на Sybase ASA, дается юзерам на инсталляшке, распаковывается без спроса и работает потом вечно. Зато у юзеров через месяц не возникает вопроса: "А почему все стало так тормозить?". Ныне 20МБ не считается расточительством дискового пространства.

← →
Sergey13 © (2004-04-27 11:28) [33]

2Курдль © (27.04.04 11:10) [29]
>Мы поставили оракл в одно очень большое мед. учреждение, где сисадмин - врач по совместительству. Комп, конечно, он включить может... :) Так что надо делать проги, чтобы они никаких спецов не требовали.
Хотел бы я видеть того врача-сисадмина при нештатной ситуации, не связанной (а может и связаной - всего не учтешь) с деятельностью твоей супер-проги. Особенно на Оракле.

← →
Курдль © (2004-04-27 11:31) [34]

> Хотел бы я видеть того врача-сисадмина при нештатной ситуации,
> не связанной (а может и связаной - всего не учтешь) с деятельностью
> твоей супер-проги. Особенно на Оракле.

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

← →
Sergey13 © (2004-04-27 11:38) [35]

Сисадмин (с БД обычно ДБА работает) обязан обеспечивать физическую целостность БД. Если вдруг носитель сбойнет, место кончится и т.п. он обязан это предупреждать и реагировать соответственным способом. Иначе какой это ДБА?

← →
Курдль © (2004-04-27 11:41) [36]

> Сисадмин (с БД обычно ДБА работает) обязан обеспечивать
> физическую целостность БД.

"
Не встречал никогда чисто-конкретно админов БД. Поэтому физическую целостность БД приходится гарантировать нам - производителям ПО. А отсюда постулат - никогда не ставить юзерам "многопользовательский парадокс" с "многопользовательским акцессом" :)))

← →
orlan master (2004-04-27 11:43) [37]

2 AntonVS:
7 лет на парадоксе практикую для малых задач. Честно скажу - все зависит от разработчика - как сделает, так работать и будет. Все от кривизны ручек зависит. То, что в парадоксе не лечится: стабильно повторяющийся синдром падения индексов при переваливании таблицы за 6 мегов. В каждом клиентском приложении внедряю сервис для интерактивного лечения возможных синдромов самими юзерами.
Стараюсь избегать разрастания базы, по мере возможности,посредством организации определенной структуры базы. Пусть лучше будет таблиц больше, нежели они будут большие и меть тенденцию к падению. "Лок-и" при сетевом решении часто задалбывают(файлы *.lck внутри каталога бызы). Малейшая коллизия - они остаются жить. Приходится гасить всех активных юзеров и вытирать локи ручками. Второй вариант - очень слабый контроль целостности базы данных. Это позавчерашний день. Все приходится реализовывать на клиенте. Настоящий изврат:( Мой принцип из практики - не использовать парадокс для сетевых решений. Однозначно.
Сам давно перебрался на MSSQL. Сервер выделенный, полный пень о 750MHz, 128 оперативки, внутри все SCSI. Такой комп ща стоит не более 400 бакинских. Не серьезные затраты для больших заказов. Под W2K все работает. 40 юзеров одновременно - полет отличный. Все от разработчика зависит, какую базу создаст. Кривая база может завалить сервер и при двух юзерах.
А заказчиков, которые диктуют что и как им надо реализовывать, и на объяснения и зравый смысл никак не реагируют - оставляю в покое. Лучше не связываться - в дальнейшем проблем будет еще больше. Клиент должен распинать что и как он ХОЧЕТ ПОЛУЧИТЬ, а не как и что НАДО ДЕЛАТЬ. Задача разработчика - предоставить желаемый результат, а не вестить на диктат заказчика как последний лох.

← →
AntonVS © (2004-04-27 11:43) [38]

>Акцесс в качестве сетевой бд ну по моему вообще изврат, не для этого его придумали, для этого мелкософт придумал МССКЛ

ну не хотят люди пользовать SQL-сервак....

>Если это и вправду Access, то ничего плохого не могу - никогда не приходило в голову использовать его, как БД :)

такая же фигня...

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

опять же для Винды - родной формат базы, если пользовать ADO, а я последнее время пользую только его(перестал доверять BDE) - без проблем цепляешься к базе...

← →
Rule © (2004-04-27 11:43) [39]

// никогда не ставить юзерам "многопользовательский парадокс" с "многопользовательским акцессом"

Вот это можно даже вместо лозунга :)

← →
Sergey13 © (2004-04-27 11:45) [40]

2Курдль © (27.04.04 11:41) [36]
>Поэтому физическую целостность БД приходится гарантировать нам - производителям ПО.
Ты сам то понял чего сказал? Процедуру на PL/SQL на крах винчестера написать что ли. 8-)

← →
Anatoly Podgoretsky © (2004-04-27 11:45) [41]

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

← →
Курдль © (2004-04-27 11:51) [42]

> Sergey13 © (27.04.04 11:45) [40]
> 2Курдль © (27.04.04 11:41) [36]
> >Поэтому физическую целостность БД приходится гарантировать
> нам - производителям ПО.
> Ты сам то понял чего сказал? Процедуру на PL/SQL на крах
> винчестера написать что ли. 8-)

Я не просто понял, что сказал, а процитировал пункт стандартного договора. Конечно, мы не гарантируем целостность БД с периодом квантования, стремящимся к 0, а вот ежедневный дампинг - всегда!

← →
Rule © (2004-04-27 11:53) [43]

>Anatoly Podgoretsky © (27.04.04 11:45) [41]
Нк как всегда АП подвел самый вразумительный итог, больше я думаю добавить нечего к всему вышесказанному

← →
Sergey13 © (2004-04-27 11:59) [44]

2Курдль © (27.04.04 11:51) [42]
Ежедневный дампинг (это экспорт я понял) - отнють не всегда спасает от физического краха.

Ветку пора в треп, а мне из инета (время подошло). 8-(

← →
Курдль © (2004-04-27 12:01) [45]

> Нк как всегда АП подвел самый вразумительный итог, больше
> я думаю добавить нечего к всему вышесказанному

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

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

← →
AntonVS © (2004-04-27 12:07) [46]

> //никогда не ставить юзерам "многопользовательский парадокс" с "многопользовательским акцессом"

м-да...

и что остается?

Dbf-ки....

думаю, если пользовать Visual FoxPro, прокатит...

но я хочу Delphi юзать...
цепляться к ним через ADO с ODBC(не BDE!, глючит он бывает)...

про DBF кто-нибудь знает какие-нибудь гадости?

под DOS в многопользовательском режиме на NetWare под клиентами на FoxPro работают без проблем...

как с виндой?

← →
sniknik © (2004-04-27 12:13) [47]

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

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

> > //никогда не ставить юзерам "многопользовательский парадокс"
> с "многопользовательским акцессом"
>
> м-да...
>
> и что остается?
>
> Dbf-ки....

Под "многопользовательский парадокс" с "многопользовательским акцессом" я имел в виду не только dbf и mdb, но и все вместе взятые дбэйсы, фоксы, кларионы, а т.ж. все, чего я не даже не знаю и знать не хочу!
Вот Вам совет, если Вы такой упорный: возьмите Yaffil Personal (он бесплатный и почти безглючный) и скажите юзерам, что это никакой не клиент-сервер! Будет у Вас (в Вашей терминологии) одна база gdb и парочка компонентов приложения dll в одном каталоге. :)

> не раз было выезжал для восстановления mssql-евской базы
>

Видимо поэтому MSSQL вызывает у меня врожденное отторжение и тоже не входит в список СУБД, с которыми я работаю. :)))

> ну не хотят люди пользовать SQL-сервак....

Какие-нибудь аргументы будут, крооме "админ боицца"? Хотят/нехотят, обычно, по каким-то причинам. Без причин ничего не бывает.

А чего, кстати, админ боицца-то? Там один файл запустить и усе, он сам поставится. И вообще, админа такого нафиг пинками..

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

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

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

кстати с превозносимым некоторыми ораклом ситуация обратная, мы с ним не работаем (1С понимаете ли ;о), ограничивает), но пытались, привозили систему на тестирование ... (не буду говорить какую, антиреклама, кому нужно для дела в частном порядке) впечатление отвратное они на "показательном выступлении" не смогли ее запустить!!! при нескольких повторяющихся AV вынуждены были отключить питание (кнопка выключения не работала, а резета на их машине не было), так вот после рестарта базу они перегенерили (сам я не понял, но их спец сказал что проблема в самом оракле, не смог восстановить базу а разбиратся и руками восстанавливать времени нет).

ну вот я и имею на балансе 1 знакомство с ораклом и 1 порушеная база, с другой стороны трудноподсчитываемое количество установок mssql в рабочем режиме и всего несколько порушенных баз, причом одну не восстановили, а несколько восстановлены все...
(возможно и ту оракловую можно было восстановить, но ... впечатление потерял :о))

← →
FatCat (2004-04-27 13:20) [54]

Привет всем!
Хочу кинуть пару слов в защиту Access. У меня он в сетевом варианте 4-й год крутится. Одни система на 7 клиентов (основная таблица - 2500-3000 записей), другая на 15-20 (основная таблица - 10000-15000 тыс. записей). Причем вторая - это подсистема приемной комиссии ВУЗа, и нагрузка у нее по сети во время "Ч" совсем не слабая. Никаких особо сильных проблем не возникало. БД сттоят на выделенном файл-сервере. Недавно для интереса перебросил БД мастером офиса в MS SQL. Нормально встала база, как родная :-), и продолжает работать. Для вашего дела один минус - клиентское приложение тоже на Access, с использованием DAO.Но ведь вопрос стоит о сетевом применении, не так ли :-)?

Anatoly Podgoretsky, т.е. если опустить вопрос импортируемости и экспортируемости, dbf и mdb - равны?

> клиентское приложение тоже на Access

ну, надеюсь Delphi не хуже Access-а управиться с mdb.

тут еще многое зависит от связуешего элемента клиента с файлом БД...

думаю, ADO справится с mdb.

Нет конечно, в во первых у них разная идеология базы, акцесс это монолит, титаник все в одном, аключая отчеты, программы и прочее.
dBase это самый первый формат баз данных для OC идеология одна таблица один файл (очень простой структуры) к нему в добавление отдельно мемо файл и файл индексов.

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

Одним из достоинств, кроме простоты, для dBase являтся очень широкая программная поддержка, кто только с этим форматом не работал. Эксель например может работать напряму без конвертирования, как на запись так и на чтение.

Можно достигнуть очень высокой стабильности за чет следующего, работать с помощью SQL и у каждой таблицы только один индекс - ID

← →
FatCat (2004-04-27 13:35) [58]

> думаю, ADO справится с mdb.

На Delphi с ADO есть у меня небольшое приложение (порядка 500-700 записей в главной таблице). Пробовал запускать его на 3-х машинах. Работает вроде нормально, единственное замечание - не очень Access любит работать через добавление записей в режиме таблицы. Лучше TQuery использовать

← →
AnD (2004-04-28 08:08) [59]

Работаю в конторе где программеры в основном 40 летние тетки которые умрут но не слезут с FoxPro. Пришлось приспосабливаться. Перепробовал куча способов доступа к DBF. Имхо лучший в плане стабильности и скорости ADO+VFP_ODBC (ODBC который идет с MSOffice - редкостные тормоза и проблемы с порядком установки, т.е. сначала ставиться Office а потом MDAC но не наоборот, и только из под пользователя, и только под админскими правами, и только если полнолуние, и etc.)
Из глюков замечено:
При очень интенсивных обращениях при закрытии соединения, могут полететь индексы. Но это редко. Данные не терялись.
На некоторых машинах проблемы при работе с VFP ODBC v5. Лечилось установкой свежего MDAC и VFP ODBC v7.

AnD, VFP_ODBC - это конкретно какой драйвер... ODBC?

и dbf - Dos-овской Fox-ой созданы?

← →
SteelAxe (2004-04-29 01:23) [61]

А что, никто про InterBase ничего не скажет? Хотелось бы послушать что мастера говорят.
В моей практике, после месяца усиленных тестирований парадоксов, Дбейсов, MySQL-ов, Акцессов я остановил свой выбор на InterBase. Опять же родная для Delphi..

> Работаю в конторе где программеры в основном 40 летние тетки
> которые умрут но не слезут с FoxPro.

Умирать не надо. Просто гнатьнах к чёрту!

> SteelAxe (29.04.04 01:23) [61]
> А что, никто про InterBase ничего не скажет? Хотелось бы послушать что мастера говорят.
А что сказать, кроме того что лично мне FireBird очень нравится!
Компактный, быстрый, бесплатный и т.д. про все это уже говорили много раз. Тут товарисч > FatCat (27.04.04 13:20) [54] писал : "другая на 15-20 (основная таблица - 10000-15000 тыс. записей)." вот я и думаю, 15-20 клиентов это понятно, а вот 10000-15000 тыс. это же получается 10-15 миллионов записей? И Access это все при "и нагрузка у нее по сети во время "Ч" совсем не слабая." тянет? Прямо зауважал я Access!

> 10000-15000 тыс. это же получается 10-15 миллионов записей?
ну до 15 нам далеко, а вот с 5 милионами есть клиент на Access-е сидит. 9-клиентов (касс) + 1-5 операторов (хотя и предупреждали что Access у нас только до 3касс), но обращения естественно не все одновременно.
ничего работает, и даже быстро (тормозов по сравнению с мелкой базой не наблюдается), вот только за 4 месяца обьем в 1,8гиг. почти максимум, часто нужно будет архивирование делать, раз в месяц к примеру, но тут сами виноваты знали на что шли.
хотя я лично под них занимался оптимизацией структуры (char на varcar, double на integer менял где возможно...) на 10% размер при тех же данных снизил (естественно ограничил саму базу, но если у них к примеру весового товара нет только штучный то нафига поле с дробями под вес?)

← →
FatCat (2004-05-05 11:44) [65]

> > 10000-15000 тыс. это же получается 10-15 миллионов записей?

Сорри, народ, это я ошибся, надо было так: 10-15 тыс. (ну или 10000-15000, как нравится), а я все сразу прилепил... ;-)
Максимальное число записей в одной из подчиненных таблиц (4 числовых поля) - до 65000 записей. Но все равно, Access"ом в плане сетевой работы я доволен - на нормальных машинах не сильно большие базы (Access поддерживает базы до 2 Гб) по сети нормально гоняются (у меня база достигала 15 Мб). Про большие размеры ничего не скажу, не пробовал, но скорее всего пойдут тормоза :-). Как выход - надо создавать несколько баз с одинаковой структурой и в запросах их собирать поочередно

2FatCat (05.05.04 11:44) [65]
>Как выход - надо создавать несколько баз с одинаковой структурой и в запросах их собирать поочередно
Это не выход - это вход в ступор.

Что бы не было тормохов, надо переходить на более прогрессивные технологии, для начала на клиент-сервер, потом можно и на сервер приложений.

← →
Chirs (2004-05-08 16:21) [68]

dbf и db - малопригодны для многопользовательской работы, да и малонадежны. Простой пример, попробуйте выключить компьютер в момент, когда происходит запись в какую-либо таблицу - в результате могут накрыться вообще все данные в таблице. Кроме того, требуется дополнительная настройка BDE и т.п., если пользователи работают с базой по сети. Я советую всем InterBase, особенно учитывая, что он идет в поставке с Delphi, серийный номер на InterBase тоже вполне можно найти в интернете.

форматы баз данных (dbf, db, mdb,...) Найти похожие ветки