ох, пак БД...
10 отговора
207 прегледа
ох, пак БД...
Да му се невиди, как не ги обичам тези БД... Човек никога не може да е сигурен какво ще се случи.
Значи ползвам access база през ODBC. Приложението, което разработваме, не трябва да е прекалено бавно, за да не дразни потребителя. Разработката се води, разбира се, под NT, но програмката трябва да работи на всичко от 95 нагоре. Дадената БД система (access + ODBC) работи задоволително бързо под NT/2000, но под 9x бързодействието пада колосално - сигурно 5-6 пъти... :(
Някой забелязал ли е този проблем и знае ли как би могла да се ускори обработката на БД? Ако няма решение - бихте ли препоръчали БД от нисък клас с ODBC драйвер, която да работи бързо и под NT и под 9x?
Благодаря предварително.
Si Vis Pacem, Para Bellum
Значи ползвам access база през ODBC. Приложението, което разработваме, не трябва да е прекалено бавно, за да не дразни потребителя. Разработката се води, разбира се, под NT, но програмката трябва да работи на всичко от 95 нагоре. Дадената БД система (access + ODBC) работи задоволително бързо под NT/2000, но под 9x бързодействието пада колосално - сигурно 5-6 пъти... :(
Някой забелязал ли е този проблем и знае ли как би могла да се ускори обработката на БД? Ако няма решение - бихте ли препоръчали БД от нисък клас с ODBC драйвер, която да работи бързо и под NT и под 9x?
Благодаря предварително.
Si Vis Pacem, Para Bellum
Отг: ох, пак БД...
хм. работил съм с абцес-97 под всякаква подържаща го среда - от 95 до 2000, минавайки през нт. не съм забелязал такъв спад на 95 или 98, при това за бази, които достигат лимита на абцеса от 1GB. специално 97 ти го препоръчвам като low-end DB -решение. виж дали не е проблем ODBC-то. и при какви точно операции се забавя така драстично - ако си по-подробен, току виж съм се сетил за нещо.
ами
Забавянето изглежда идва главно от тегленето на данни. Те винаги са binary
Si Vis Pacem, Para Bellum
Si Vis Pacem, Para Bellum
Отг: ох, пак БД...
И аз усещах чуствително забавяне, когато ползвах слюза на Borland т.е BDE който минава през ODBC за достъп до една таблица на Access... Ама това забавяне е само заради BDE, иначе ODBC-то си е добро.
Цъ-цъ-цъ-цъ...Мамка му
... Спомням си първата (от 3 на брой срещи с "абцеса"). На моя гаден шеф,
му бяха пробутали && продали, програма с зле неизяснени лицензионни
опции. И...той беше много нервен. Ми що е толкова тъп? Но това е друга
тема. Важното, че и разработчика излезе, "малко прос". Поразкрасил
малко .MDB-то, и си мисли, че мнооого го скрил. Та се наложи, заради
данните и да ги прекарам през BDE && ODBC с една моя програмка.
Е кво да ви кажа? Без BDE и с него- почти все там. Ако бях достатъчно
компетентен, щях да ревна:
- Я не ми ги разправяйте тия ! ODBC да работи бързо? Друг път !.
Що се отнася за бинарните данни, МИГ-31, малко съм очуден. Подозирам, че
ти гледаш кино или графики. Но дори и да говорим въобще за някакъв BLOB,
това не вярвам да има особенно значение. Освен процедурата за четенето да
не се налага много да се "изчаква" с други. Все пак тука няма ДБ сърверски
процес, които да туря някакъв ред. Ако все пак съм прав за графиката, все
си мисля, че Access не е на-добрия инструмент. Струва ми се, че в такива
случаи най-добро би било яка, обектно ориентирана БД, или нещо адски
"просташко" - файлов сървер, който търси "файлчета". Баси....
А, сега отивам да пророня някоя сълза, за доброто старо време -
(good old time - GOT !), дето имаш един файлов сървер, който се шашка от
логически дублирани "заявки", не умее да кешира, жиците му чак светят от
кошии, а преизпълнените му с логика "клиенти" се ритат като "атове", кой
пъври да оправи нещата, и тъй-нататък. И все се чудя, как имах ( и все още
имам) чудна скорост и надежност ?
Поздрави: Любо
му бяха пробутали && продали, програма с зле неизяснени лицензионни
опции. И...той беше много нервен. Ми що е толкова тъп? Но това е друга
тема. Важното, че и разработчика излезе, "малко прос". Поразкрасил
малко .MDB-то, и си мисли, че мнооого го скрил. Та се наложи, заради
данните и да ги прекарам през BDE && ODBC с една моя програмка.
Е кво да ви кажа? Без BDE и с него- почти все там. Ако бях достатъчно
компетентен, щях да ревна:
- Я не ми ги разправяйте тия ! ODBC да работи бързо? Друг път !.
Що се отнася за бинарните данни, МИГ-31, малко съм очуден. Подозирам, че
ти гледаш кино или графики. Но дори и да говорим въобще за някакъв BLOB,
това не вярвам да има особенно значение. Освен процедурата за четенето да
не се налага много да се "изчаква" с други. Все пак тука няма ДБ сърверски
процес, които да туря някакъв ред. Ако все пак съм прав за графиката, все
си мисля, че Access не е на-добрия инструмент. Струва ми се, че в такива
случаи най-добро би било яка, обектно ориентирана БД, или нещо адски
"просташко" - файлов сървер, който търси "файлчета". Баси....
А, сега отивам да пророня някоя сълза, за доброто старо време -
(good old time - GOT !), дето имаш един файлов сървер, който се шашка от
логически дублирани "заявки", не умее да кешира, жиците му чак светят от
кошии, а преизпълнените му с логика "клиенти" се ритат като "атове", кой
пъври да оправи нещата, и тъй-нататък. И все се чудя, как имах ( и все още
имам) чудна скорост и надежност ?
Поздрави: Любо
Отг: ох, пак БД...
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?
Chuval sam che po printsip ODBS zabavia dosta cheteneto. Zasto ne opitas sas dostap s ADO komponenti?
Отг: ох, пак БД...
Понеже за ADO се използва native OLE DB Provider for JET може и да се позабърза, но едва ли ще е кой знае колко. Най-вероятно спадането на бързодействието е страничен ефект и доста ще трябва да се рови, освен ако човек няма късмет
Отг: ох, пак БД...
Оффф... ODBC е най-бавното нещо което съм виждал. Ако има начин, ползвай Personal Oracle 8i - като му спреш java-та е страшно добър, но връзката да е през ОО4О примерно а не през ODBC...
A, и ако това наистина са картинки тия BLOB-ове... ако ги пишеш в файлове, или нещо такова, FAT-a не се справя добре с голям брой файлове в сравнение с NTFS-то...имах такъв проблем тука...
Rgrds,
Malcolm
A, и ако това наистина са картинки тия BLOB-ове... ако ги пишеш в файлове, или нещо такова, FAT-a не се справя добре с голям брой файлове в сравнение с NTFS-то...имах такъв проблем тука...
Rgrds,
Malcolm
хмм
може би е фалшива тревога, в понеделник ще видим :))
иначе благодаря на всички за съдействието :)
Si Vis Pacem, Para Bellum
иначе благодаря на всички за съдействието :)
Si Vis Pacem, Para Bellum
Отг: хмм
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
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