Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2003.01.23;
Скачать: [xml.tar.bz2];

Вниз

Top10   Найти похожие ветки 

 
TTCustomDelphiMaster   (2003-01-04 19:05) [0]

Где-то здесь видел рейтинг Paradox - отстой, Access - уже лучше, Firebird - само-то.
Можно поподробнее об этих и других базах (Минимальные, оптимальные требования - производительность, явные минусы - плюсы, под какими OS работают под какими нет)

Вот мне нужно сделать базу ~10000 записей работает на 1 компьютере(P2 - 200-300Мгц) Win98. И что без SQL сервера никак не обойтись?


 
MsGuns   (2003-01-04 19:33) [1]

Paradox (BDE) - самый быстрый, но самый нестабильный (точнее требует большого опыта при проектировании топологии и организации доступа в приложениях

Access - достаточно стабильный но медленный (по сравнению с BDE)

IB - по надежности не хуже Acsess, но и быстрее его, но медленнее Парадокса

А вообще выбор БД зависит от сложности информации, кол-ва юзеров, требований к надежности и т.д.


 
TTCustomDelphiMaster   (2003-01-04 19:39) [2]


> но самый нестабильный


Как это проявляется. Портятся файлы при аварийном завершении работы или что?


 
MsGuns   (2003-01-04 20:24) [3]

Сейчас занят, отвечу подробно позже. Возобнови сабж завтра после обеда.


 
sniknik   (2003-01-05 08:39) [4]

> но самый нестабильный
проявление следующие, у нас в разных местах обмен идет через Парадох (реализация нам по наследству досталась) позже стали использовать MSSQL (это уже чисто наше) еще посже Access (причины "опускания" чисто политические).

так вот в места с парадоксом больше всего вызовов, индексы рушатся, сами таблици заголовки теряют, бывают вообще странные веши например переполнение таблиц (128мг должно быть по расчетам 20мг макс) ничего не пишется но после сжатия оказывается 4мг. ?? как получилось? не знаю там же страничная организация, удаленные записи используются повторно. жалею что не сохранил разобратся.

там где MSSQL, Access вызовы были только попервой и то наши же глюки исправляли (никакое тестирование все не выявит).

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


 
VAleksey   (2003-01-05 08:54) [5]


> > но самый нестабильный

А у меня уже ни одного вызова в течении 8-ми месяцев. :)) Правда пришлось попотеть над утилитками для восстановления paradox :).


 
passm   (2003-01-05 09:33) [6]

> но самый нестабильный
У меня уже 4 года стабильной работы :)


 
sniknik   (2003-01-05 10:40) [7]

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

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

p.s. наверное немного сгустил краски, это всетаки редко бывает, но тем не менее все ситуации реально были.


 
ak   (2003-01-05 11:12) [8]

2 sniknik.
Как я тебя понимаю!!!!
У нас такие приколы чуть ли не через день происходят. Не только с БД, а вообще с системой в целом. Самый убойный случай был: звонят клиенты, так и так комп не работает. Прихожу, гружусь с системной дискетки и что я вижу (надо отметить, что в предыдущий раз я им долго объяснял "файлы io.sys, msdos.sys и т.д. вовсе не мусор, их ни в коем случае нельзя удалять): на диске С каталог "Системные файлы" и в ней все системные файлы лежат! Я аж разрыдался от смеха!


 
VAleksey   (2003-01-05 12:09) [9]


> sniknik © (05.01.03 10:40)

Тихо плачу
офигел я :))
Прими мои соболезнования !!!!!!!!


 
sniknik   (2003-01-05 12:43) [10]

VAleksey © (05.01.03 12:09)
> Прими мои соболезнования !!!!!!!!

Да мне то как раз не зачем. Основные "удары" ЦТО принимает. А по прошествии некоторого времени как анекдоты всем расказывают. Веселятся. И расстраиваются не особо (разве что приходится в ночь или на выходные выезжать).


 
TTCustomDelphiMaster   (2003-01-05 14:29) [11]


> sniknik © (05.01.03 08:39)
> индексы рушатся, сами таблици заголовки теряют, бывают вообще
> странные веши

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


> VAleksey © (05.01.03 08:54)

От каких поломок эти утилитки помогают. Как обнаруживают что база поломалась?



> passm © (05.01.03 09:33)

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


> sniknik © (05.01.03 10:40)
> повезло вам с юзерами, я смотрю.

Действия пользователя направленные на уничтожение базы я не рассматриваю как нестабильную работу базы. Меня интересует надежность базы при нормальных условиях работы и при внешних воздействиях (зависание компьютера, завершение работы программы при нажатии CAD + Завершить процесс, отлючение электропитания).


 
TTCustomDelphiMaster   (2003-01-05 14:53) [12]

Удалено модератором
Примечание: Модератора не обсуждаем


 
sniknik   (2003-01-05 18:06) [13]

послушать юзеров так "мы ничего не делали, все порушилось само по себе", только припертые к стене признаются. :-))

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

TTCustomDelphiMaster © (05.01.03 14:29)
А в результате чего это происходило? ...внутренние глюки BDE.
если б знать! каждый раз по разному.
BDE в нашем случае совсем не при чем. выкладывает дос программа (супермаг может знаете) а "забор" идет через ADO-Jet.

TTCustomDelphiMaster © (05.01.03 14:53)
модератора ругал? за то что в потрепатся перекинули?
не обижайся все ветки по обсуждению какая база лутше так или иначе сюда перекочовывали. (и самое им здесь место)


 
TTCustomDelphiMaster   (2003-01-05 19:34) [14]


> TTCustomDelphiMaster © (05.01.03 14:53)
> модератора ругал? за то что в потрепатся перекинули?

Да нет не ругал, наоборот обьявил благодарность.


 
TTCustomDelphiMaster   (2003-01-05 19:34) [15]

Выходит зря ругают Paradox?

Может Уважаемый MsGuns что нибуть скажет.


 
MsGuns   (2003-01-05 20:46) [16]

>TTCustomDelphiMaster © (05.01.03 19:34)
>Выходит зря ругают Paradox?

>Может Уважаемый MsGuns что нибуть скажет.

Простой пример. Ездил на велосипеде, потом купил жигуль. На жигуле круче, но велик-то тоже не плох, не так ли ?

А вообще-то когда говорят, что та или иная БД - отстой, это, как правило, свидетельствует не о качестве СУБД, а о проф.качествах программеров. Как говорится, не бывает некрасивых женщин - бывает мало водки ! ;))))


--------------------------------------------------------------------------------


 
TTCustomDelphiMaster   (2003-01-05 21:55) [17]

Так все таки почему вы считаете что Access достаточно стабильнна а Paradox (BDE) самый нестабильный?


 
MsGuns   (2003-01-05 22:28) [18]

>TTCustomDelphiMaster © (05.01.03 21:55)
>Так все таки почему вы считаете что Access достаточно стабильнна а Paradox (BDE) самый нестабильный?

Серверные СУБД сделаны по принципу "закрытых" БД, вся кухня в которых выполнена на внутреннем уровне. Программеру надо лишь использовать предоставляемые системой средства и методы. При этом у него "не болит голова" от том как именно выполняются те или иные действия. Т.е. это программирование на более высоком уровне. Но и "издержки" (несовершенство, глюки и т.д.) от него также не зависят. Они как бы прилагаются. При работе же с локальными БД у программера и разработчика БД значительно больше свободы, но и ответственность за качественно функционирующую БД так же выше. Я бы сравнил эти 2 подхода с программированием низкоуровневым (ассеммблер) и высокоуровневым (Паскаль), хотя, конечно, сравнение несколько грубоватое. Однозначно, что издержки на серверные СУБД (дисковая память, понижение быстродействия, относительно высокая цена, невозможность или затруднительность гибкого (на физ.уровне, например) редактирования) выше, чем для Парадокса, например. Но, принимая во внимание все растущую мощь выч.техники и существенную экономию времени на проектирование и, особенно, на сопровождение (администрирование) БД, первый метод, безусловно, предпочтительнее. Особенно для больших БД или таких, которые требуют повышенной надежности. Хотя в большинстве случаев, к примеру для небольших организаций, вполне может нормально работать и Парадокс. Если, конечно, разработчик заранее позаботился о простых и удобных средствах ремонта-восстановления информации.

И еще о парадоксе. Для эффективного его применения, особенно в сетевых многопользовательских системах, весьма желательно понимать механизм работы BDE с его таблицами (всякие там lck-шки, файлы с раширениями Xnn, Ynn, Val, px и проч.), хорошо представлять себе механизм блокировок и умело им манипулировать.
К сожалению, большинство вопросов и претензий к BDE связано именно с неправильной организацией доступа к данным, допущенной как на этапе проектирования БД, так и на этапе разработки приложений.

Серверные СУБД избавляют разработчика от необходимости такого понимания. Именно поэтому, ИМХО, за ними будущее.

В заключение, я бы лично рекомендовал использовать парадокс для небольших БД (до 20 таблиц) с несложной логикой организации данных (топологией) и предельным числом одновременно подключенных пользователей до 4-5 без выделенного файл-сервера и до 15 с выделенным. И в тех случаях, когда по каким-то причинам заказчику невозможно установить высокопроизводительный SQL-сервер.

Это, естественно, мое ЛИЧНОЕ мнение, которое отнюдь не претендует на абсолютность.

С уважением. Щербаков Сергей


 
TTCustomDelphiMaster   (2003-01-05 22:38) [19]

Щербаков Сергей, спасибо за очень интересный и подробный ответ.


 
MsGuns   (2003-01-05 22:48) [20]

>TTCustomDelphiMaster © (05.01.03 22:38)

На здоровья и успехов !;)


 
Pat   (2003-01-05 23:53) [21]

"Маленький" глюк BDE из личного "опыта" :-))
Допустим, есть Парадоксовская таблица try.db:
ID - Autoincrement * (ключевое)
Dep - Alpha 30
Val - Short
Создаем вторичный индекс:
Dep
Val
Пишем небольшой запрос:

with TQuery.Create(application) do
try
DatabaseName:="Work";
SQL.Add("update try set val=1");
SQL.Add("where dep=""a""");
ExecSql
finally
free
end;

При выполнении запроса тачка виснет, прога снимается через CAD, BDE еще некоторое время "не может придти в себя", т.е. программы, использующие BDE не работают...
Может объясните в чем дело? :-))
Кстати, если во вторичном индексе поле dep не будет первым, то запрос нормально работает.



Страницы: 1 вся ветка

Форум: "Потрепаться";
Текущий архив: 2003.01.23;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.52 MB
Время: 0.008 c
6-72438
Walker
2002-11-17 02:40
2003.01.23
IS филтры


1-72318
Gerda
2003-01-14 22:48
2003.01.23
По поводу коммон контрола SysListView32


1-72303
badaxe
2003-01-15 15:37
2003.01.23
Проблема с random


1-72336
Schummi
2003-01-02 14:36
2003.01.23
TChart в два ряда


1-72321
Dor
2003-01-15 20:25
2003.01.23
в timer1.timer из memo1.lines текст сохранялся в эту дерикторию





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский