Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 4 >
AntonVS © (2004-04-26 14:25:00)
хочу поднять пару-тройку вопросов (может быть даже - филосовских)

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

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

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

Курдль (2004-04-27 12:14:00) [21]

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

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

sniknik (2004-04-27 12:13:00) [22]
> все более-менее умные СУБД не рушатся даже при отключении питания, вплоть до последней транзакции.
будет правильнее сказать что они пытаютсяне рушится. ;о))

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

AntonVS (2004-04-27 12:07:00) [23]
> //никогда не ставить юзерам "многопользовательский парадокс" с "многопользовательским акцессом"

м-да...

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

Dbf-ки....

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

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

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

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

как с виндой?

Курдль (2004-04-27 12:01:00) [24]

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

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

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

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

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

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

Курдль (2004-04-27 11:51:00) [27]

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

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

Anatoly Podgoretsky (2004-04-27 11:45:00) [28]
Да для локальных баз без разницы файл-серверная технология или клиент серверная, вторая даже хуже по надежности, когда грохнется тяжелее с восстановлением. Нужен выделеный сервер с бесперебойным источником питания, после этого можно забыть о проблемах, а какую клиент-серверную систему использовать не так уж и важно при такой нагрузке.

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

Rule (2004-04-27 11:43:00) [30]
// никогда не ставить юзерам "многопользовательский парадокс" с "многопользовательским акцессом"

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

AntonVS (2004-04-27 11:43:00) [31]
>Акцесс в качестве сетевой бд ну по моему вообще изврат, не для этого его придумали, для этого мелкософт придумал МССКЛ

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

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

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

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

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

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

Курдль (2004-04-27 11:41:00) [33]

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

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

Sergey13 (2004-04-27 11:38:00) [34]
Сисадмин (с БД обычно ДБА работает) обязан обеспечивать физическую целостностьБД. Если вдруг носитель сбойнет, место кончится и т.п. он обязан это предупреждать и реагировать соответственным способом. Иначе какой это ДБА?

Курдль (2004-04-27 11:31:00) [35]

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

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

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

Курдль (2004-04-27 11:25:00) [37]

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

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

Rule (2004-04-27 11:21:00) [38]
>Sergey13 © (27.04.04 11:12) [30]
согласен на все сто

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

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

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

Курдль (2004-04-27 11:10:00) [40]

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

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

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

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »