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

← →
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-ок (или не включены по какимто причинам). восстановить удалось все (пока что, но всех предупреждаем в таких случаях - никаких гарантий)

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

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

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

← →
sniknik © (2004-04-27 12:16) [49]

AntonVS © (27.04.04 12:07) [46]
> и что остается?
не иши самого лутшего/безглючного нет такого.

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

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

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

← →
Danilka © (2004-04-27 12:17) [51]

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

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

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

← →
Anatoly Podgoretsky © (2004-04-27 12:19) [52]

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

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

← →
sniknik © (2004-04-27 12:33) [53]

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

кстати с превозносимым некоторыми ораклом ситуация обратная, мы с ним не работаем (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.Но ведь вопрос стоит о сетевом применении, не так ли :-)?

← →
AntonVS © (2004-04-27 13:23) [55]

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

← →
AntonVS © (2004-04-27 13:26) [56]

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

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

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

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

← →
Anatoly Podgoretsky © (2004-04-27 13:31) [57]

Нет конечно, в во первых у них разная идеология базы, акцесс это монолит, титаник все в одном, аключая отчеты, программы и прочее.
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,...) Найти похожие ветки