ох, пак БД...

10 отговора 207 прегледа
#1

ох, пак БД...

Да му се невиди, как не ги обичам тези БД... Човек никога не може да е сигурен какво ще се случи.
Значи ползвам access база през ODBC. Приложението, което разработваме, не трябва да е прекалено бавно, за да не дразни потребителя. Разработката се води, разбира се, под NT, но програмката трябва да работи на всичко от 95 нагоре. Дадената БД система (access + ODBC) работи задоволително бързо под NT/2000, но под 9x бързодействието пада колосално - сигурно 5-6 пъти... :(
Някой забелязал ли е този проблем и знае ли как би могла да се ускори обработката на БД? Ако няма решение - бихте ли препоръчали БД от нисък клас с ODBC драйвер, която да работи бързо и под NT и под 9x?
Благодаря предварително.


Si Vis Pacem, Para Bellum
Отговор
в отговор на MиГ-31 #2

Отг: ох, пак БД...

хм. работил съм с абцес-97 под всякаква подържаща го среда - от 95 до 2000, минавайки през нт. не съм забелязал такъв спад на 95 или 98, при това за бази, които достигат лимита на абцеса от 1GB. специално 97 ти го препоръчвам като low-end DB -решение. виж дали не е проблем ODBC-то. и при какви точно операции се забавя така драстично - ако си по-подробен, току виж съм се сетил за нещо.

Отговор
в отговор на Kpoмид #3

ами

Забавянето изглежда идва главно от тегленето на данни. Те винаги са binary

Si Vis Pacem, Para Bellum
Отговор
в отговор на MиГ-31 #4

Отг: ох, пак БД...

И аз усещах чуствително забавяне, когато ползвах слюза на Borland т.е BDE който минава през ODBC за достъп до една таблица на Access... Ама това забавяне е само заради BDE, иначе ODBC-то си е добро.

Отговор
в отговор на MиГ-31 #5

Отг: ами

да не би тоя 9х на който пробвате да е с много малко памет?


Пламен
Отговор
в отговор на MиГ-31 #6

Цъ-цъ-цъ-цъ...Мамка му

... Спомням си първата (от 3 на брой срещи с "абцеса"). На моя гаден шеф,
му бяха пробутали && продали, програма с зле неизяснени лицензионни
опции. И...той беше много нервен. Ми що е толкова тъп? Но това е друга
тема. Важното, че и разработчика излезе, "малко прос". Поразкрасил
малко .MDB-то, и си мисли, че мнооого го скрил. Та се наложи, заради
данните и да ги прекарам през BDE && ODBC с една моя програмка.
Е кво да ви кажа? Без BDE и с него- почти все там. Ако бях достатъчно
компетентен, щях да ревна:

- Я не ми ги разправяйте тия ! ODBC да работи бързо? Друг път !.

Що се отнася за бинарните данни, МИГ-31, малко съм очуден. Подозирам, че
ти гледаш кино или графики. Но дори и да говорим въобще за някакъв BLOB,
това не вярвам да има особенно значение. Освен процедурата за четенето да
не се налага много да се "изчаква" с други. Все пак тука няма ДБ сърверски
процес, които да туря някакъв ред. Ако все пак съм прав за графиката, все
си мисля, че Access не е на-добрия инструмент. Струва ми се, че в такива
случаи най-добро би било яка, обектно ориентирана БД, или нещо адски
"просташко" - файлов сървер, който търси "файлчета". Баси....

А, сега отивам да пророня някоя сълза, за доброто старо време -
(good old time - GOT !), дето имаш един файлов сървер, който се шашка от
логически дублирани "заявки", не умее да кешира, жиците му чак светят от
кошии, а преизпълнените му с логика "клиенти" се ритат като "атове", кой
пъври да оправи нещата, и тъй-нататък. И все се чудя, как имах ( и все още
имам) чудна скорост и надежност ?

Поздрави: Любо

Отговор
в отговор на MиГ-31 #7

Отг: ох, пак БД...

Rabotia s BDE i BLOB poleta po 1 - 3 MB. Mislia che zabavianeto ne e sastestveno po goliama ot kolkoto ako gi cheta direktno kato fajlove.

Chuval sam che po printsip ODBS zabavia dosta cheteneto. Zasto ne opitas sas dostap s ADO komponenti?

Отговор
в отговор на Tapanar_anon #8

Отг: ох, пак БД...

Понеже за ADO се използва native OLE DB Provider for JET може и да се позабърза, но едва ли ще е кой знае колко. Най-вероятно спадането на бързодействието е страничен ефект и доста ще трябва да се рови, освен ако човек няма късмет

Отговор
в отговор на Zhivko_anon #9

Отг: ох, пак БД...

Оффф... ODBC е най-бавното нещо което съм виждал. Ако има начин, ползвай Personal Oracle 8i - като му спреш java-та е страшно добър, но връзката да е през ОО4О примерно а не през ODBC...
A, и ако това наистина са картинки тия BLOB-ове... ако ги пишеш в файлове, или нещо такова, FAT-a не се справя добре с голям брой файлове в сравнение с NTFS-то...имах такъв проблем тука...

Rgrds,
Malcolm

Отговор
в отговор на MиГ-31 #10

хмм

може би е фалшива тревога, в понеделник ще видим :))
иначе благодаря на всички за съдействието :)

Si Vis Pacem, Para Bellum
Отговор
в отговор на MиГ-31 #11

Отг: хмм

Nachi Access - ne mersi.
ODBC - nai-bavnoto reshenie kakvoto i da pravish.

Edno empirichno pravilo
M-u 500k i 1Mb ima edna granica pri koiato e po-dobre da ne se pazi BLOB a ime na fail.
Tova zavisi ot OS, File system i razni drugi neshta.
No takava granica VINAGI ima.
Taka ili inace Access e low-end (lowest) DB
Koito i da e SQL server shte se spravi po-dobre

Отговор