Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
 Re: Поругайте Акцесс. Очень надо.  [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
а на аксесе можно клиента к fb сделать?
21 янв 04, 12:48    [500641]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
aPT
Member

Откуда:
Сообщений: 180
Можно, но не нужно.
21 янв 04, 12:52    [500655]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
fedd
Member

Откуда: Москва
Сообщений: 33999
можно, если есть одибиси. я когда боялся командной строки, через аксесс с мойсквелем работал.... делов то.

но там есть спецфича по работе с MSSQL - это правда. то есть база на MSSQL, а морда - на Access. Это сочетает плюсы аксеса как средства быстрой и красивой виндовой разраобтки и клиент-серверных технологий, о чем мужики из аксессного форума и пытались сказать, круто загибая пальцЫ ;))
21 янв 04, 12:56    [500677]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Senin Viktor
Member

Откуда: Подмосковье
Сообщений: 5006
2alex_k
Коллега!
Теперь и я прошу быть внимательней :)
Я же сказал "скорей всего" быстрей, а не одназначно "быстро, супер быстро".
Есно, все зависит от уровня знания прогеров и наличии "домашних заготовок".

И, если можно, расскажи, что в Акесе занимает часы, а в Дельфи - минуты. Возможно смогу подсказать, как и на Акесе сделать быстрей. Только, конечно, задавай вопрос в форуме по Акесу, ну, или пиши на е-маил: senin_job#zyx.ru
21 янв 04, 13:51    [500803]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
c127
Guest
2 Eternal

Благодарю за цитатку, развеселил. "Старший брат FoxPro, если так можно выразиться, - это продукт фирмы Oracle - вечный конкурент Microsoft в секторе СУБД."

2 aPT

Успехов.
21 янв 04, 23:09    [501740]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Для меня главным недостатком ACCESS, впрочем как и любой другой файл- серверной БД, является отсутствие транзакций. Любой аппаратный сбой может привести в к появлению в базе неполных и противоречивых данных.

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

Недостаток спорный, но присутствующий. M$ уже отказалось от развития Jet. Наверняка создатели проги на VB работают через него. Если в будущем в Jet обнаружится дыра, то не факт, что M$ будет ее латать. А переход с Jet на ODBC штука не совсем тривиальная, особенно если вся логика делается на клиенте.

SQL-сервера обладают более развитой системой разрешения доступа. Если даже сейчас этой гибкости не надо, то это не значит, что она не появится через некоторое время.

Разные версии Access не совместимы. Пускай сейчас стоит самая современная. Через некоторое время она станет "предыдущей". И будет очень весело, когда кто-нибудь их крутых юзеров откроет базу Access-2002 из Access-2005 и переконвертит ее в новый формат. Это не смертельно, но на пол дня работа будет парализована. Это конечно слабый аргумент, но все же.
21 янв 04, 23:49    [501750]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Cat2, не ешь коричневые грибы

Для меня главным недостатком ACCESS, впрочем как и любой другой файл- серверной БД, является отсутствие транзакций.
В аксесе всю жизнь были мало того что транзакции, так еще и изначально распределенные, и полноценно вложенные друг в друга
Любой аппаратный сбой может привести в к появлению в базе неполных и противоречивых данных
Аппаратный сбой может привести к появлению в базе чего угодно. И не только в аксесе, но и в любой СУБД. От царапанья головок по винту ничто не спасет. Другое дело, что в аксесе система управления распределена по всем клиентам сразу, и из-за этого страдает общая надежность. Это минус. Но с транзакциями это не связано.
Работая с аксесом получить неполные и противоречивые данные в результате сбоя на клиенте - это еще постараться надо. В 99% сбоев будет просто падение базы в откатом всех незавершенных транзакций. При этом достаточно маломальски грамотного построения сети, чтобы сбои были сами по себе редкостью (максимум раз в несколько месяцев)

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

Недостаток спорный, но присутствующий. M$ уже отказалось от развития Jet. Наверняка создатели проги на VB работают через него. Если в будущем в Jet обнаружится дыра, то не факт, что M$ будет ее латать.
Для Jet 4.0 и так уже восьмой сервис пак вышел. Куда уж дальше то латать :)
Вон, к NT не выходит сервис-паков (после 6-го) - дык и на фиг не надо.

Разные версии Access не совместимы.
По формату данных - обратная совместимость полная. Из 2002-го аксеса спокойно линкуйся к аксесу 2.0 и работай.
По VBA-коду, библиотекам, формочкам и прочее - начиная с 97-го все более новые версии нормально конвертируются в новый формат. 2002-й и 2003-й спокойно исполняют код 2000-го и выше даже без конвертации.
Это только с переводом аксеса 2.0 на 97-й были серьезные проблемы. Но когда это было?

когда кто-нибудь их крутых юзеров откроет базу Access-2002 из Access-2005 и переконвертит ее в новый формат
mde/ade тебе в помощь. устанет юзер мде конвертить :)

SQL-сервера обладают более развитой системой...
Более развитой системой всего чего угодно. Давай не сравнивать мотоцикл с камазом? В булочную на камазе ездить не станешь.
Аксес в формате мдб - настольная база. У него свой сегмент.
В формате адп - весьма неплохой клиент к MS SQL. Гиперфункциональность и бешеная скорость разработки клиента (хотя и своих тараканов хватает).
Есть еще и формат "мдб+одбц+любой sql server", но это извращение. мутант мертворожденный. годится только как временное решение.
22 янв 04, 01:48    [501774]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
# Darth Vader #
Member

Откуда: С ит колхоза
Сообщений: 7731
2 ЛП
>В булочную на камазе ездить не станешь.
Это точно.

Так ведь надо было Access в этом топике опустить перед FB, а ты его расхваливаешь.
22 янв 04, 09:07    [501920]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Eternal
Я не расхваливаю. Я указываю на ошибки в ругани других.
На FB мне вообще пофиг, я зверя такого не знаю, поэтому опустить аксес перед FB - да легко! Крекс-фекс-пекс-аксес опустись! Контрольный трахтибидох!
Как можно ругать какое-то средство не зная задачи, для решения которой оно было выбрано? А тут ничего не известно, кроме того, что 10 пользователей и 100000 записей.

2 Cat2
Во! Вспомнил, что ты действительно забыл в указании недостатков! Отсутствие триггеров. В совокупности с обработкой на клиенте - оч нехорошо. Приходится извращаться.
З.Ы. Еще раз приколюсь над фразой "отсутствие транзакций в любой файл- серверной БД".
В MySQL вроде тоже не было транзакций? Теперь вроде они появились, но правда ли, что MySQL когда-то тоже был файл-серверной БД?
22 янв 04, 13:06    [502549]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
2ЛП: Транзакции Access, к сожалению, не всегда спасут от сбоев в работе, особенно в сетевой базе. Сам с этим сталкивался.
22 янв 04, 14:16    [502750]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Транзакции Access, к сожалению, не всегда спасут от сбоев в работе, особенно в сетевой базе.
Двумя руками за! Действительно не спасут. И я с этим сталкивался.
И от сброса чугуниевой бомбы на хрупкий винчестер - тоже не спасут (хоть я с этим не сталкивался).
Да и не должны транзакции этим заниматься. Транзакция - это логическая единица работы (определение из Дейта), к системе обеспечения отказоустойчивости относится постольку поскольку, в ACID св-вах ни слова о сбоях.

Продолжаю цитировать Дейта:
"Замечание. Тема восстановления носителей представляет собой нечто совершенно самостоятельное и не имеющее отношения к транзакциям и восстановлению системы после сбоев. Она включена в данное обсуждение только для завершенности всей картины."

Устал цитировать Дейта. В общем, есть "мягкие отказы" (не нарушающие физического состояния базы) и "жесткие отказы" (например, отказ носителя).
Если мы говорим о "мягких отказах" - то транзакции в аксесе работают ровно так, как им и положено. Если о "жестких" (база рухнула, причем рухнула экстремально) - то механизм транзакций тут и не при чем.
22 янв 04, 14:33    [502806]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 LP

Устал слушать ахинею, только по этой причине пишу. Транзакции подразумевают (четвертым свойством ACID) ДЛИТЕЛЬНОСТЬ. Т.е. при фиксации транзакции, информация сохраняется (надолго). Это подразумевает устойчивость к сбоям (в том числе и аппаратным). От сброса чугуниевой бомбы спасает backup/recovery в нормальных СУБД ОЧЕНЬ сильно завязанная на понятие транзакций.
22 янв 04, 15:24    [502962]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Т.е. при фиксации транзакции, информация сохраняется (надолго)
Что и происходит в аксесе. Если фиксация, конечно, прошла. Вопросы?

От сброса чугуниевой бомбы спасает backup/recovery в нормальных СУБД ОЧЕНЬ сильно завязанная на понятие транзакций.
Она может быть хоть узлом завязана, мне то что?
В MySQL бекапов нет совсем, да? Потому как там транзакций нет? Сори, не было раньше. Да?
Не смешите мои тапки. В следующий раз будете проходить мимо - проходите дальше. Не слушайте ахинею.
22 янв 04, 15:38    [502998]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Я сказал в нормальных СУБД
22 янв 04, 16:10    [503082]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
f_w_p
Guest
В MySQL бекапов нет совсем, да? Потому как там транзакций нет? Сори, не было раньше. Да?
А и вправду, как без транзакций сделать BACKUP?
22 янв 04, 16:18    [503102]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Глюк
Я сказал в нормальных СУБД
А Дейт, видать, писал исключительно про плюшевые СУБД, ибо (еще раз):
"Тема восстановления носителей представляет собой нечто совершенно самостоятельное и не имеющее отношения к транзакциям и восстановлению системы после сбоев."

То, что система транзакций может быть использована системой backup/recovery - да пожалуйста. Лишний плюс ораклу и всем кто так делает. Только не надо ставить знак равенства между этими двумя системами.
И вообще, мы здесь аксес ругаем, а не оракл хвалим :)

2 f_w_p
А и вправду, как без транзакций сделать BACKUP?
А хрен его знает товарисч майор.
Взять палку, выгнать всех из базы нафиг, и тупо сделать бекап путем копирования файлов с данными :)
В аксесе так и делается (попрошу заметить - не потому что транзакций нет :))
Cat2 об этом уже упомянул. Интересно послушать обладателей 2003-го аксеса - сделали там то, о чем так долго говорили большевики (бекап базы без выгоняния всех юзеров)?
22 янв 04, 16:31    [503133]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
ЛП
Интересно послушать обладателей 2003-го аксеса - сделали там то, о чем так долго говорили большевики (бекап базы без выгоняния всех юзеров)?


Нет. На сколько я понимаю, при бэкапе база должна быть открыта монопольно.

А что касается транзакций, в целом ты прав, но если, допустим, MSSQL откатит все незавершенные транзакции после сбоя, то от Access'а, по понятным причинам, этого ждать не приходится. Я об этом речь и вел. Надеюсь мы поняли друг друга. :)

ЛП
И вообще, мы здесь аксес ругаем


Вот именно, так что не влезай в оффтопик. ;)
22 янв 04, 16:51    [503191]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
допустим, MSSQL откатит все незавершенные транзакции после сбоя, то от Access'а, по понятным причинам, этого ждать не приходится
А что он по твоему сделает? Commit?
У меня дежавю? Не далее как вчера вечером я задавал этот вопрос в ответ на подобное же утверждение в форуме по аксесу.

На сколько я понимаю, при бэкапе база должна быть открыта монопольно.
Не вижу предпосылок для такого утверждения.
Понятно, почему в предыдущих версиях (до 2002-го включительно) нельзя сделать бекап не выгнав предварительно всех. Просто потому, что в аксесе отсутствует как явление встроенная в аксес же система резервного копирования. Приходится бекапить внешними средствами, что нереально при работающих в базе пользователях - во всех базах без исключения, а не только в аксесе.
Почему нельзя сделать встроенное в аксес средсво для бекапа, или почему для бекапа надо открывать базу монопольно - мне пока непонятно.

И вообще, мы здесь аксес ругаем
Вот именно, так что не влезай в оффтопик. ;)

Ну ладно, давай поругаем
Аксес - АЦТОЙ!
Патамушта не умеет делать бекап, в нем не могут работать больше пяти юзеров, при размере базы больше одного мегабайта - тормоза чугуниевые, в нем нет транзакций, и вообще он для хранения данных использует экселевские файлы!
У меня хорошо получилось?
22 янв 04, 17:04    [503213]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Мимо пробегал...
Guest
MSSQL откатит все незавершенные транзакции после сбоя, то от Access'а, по понятным причинам, этого ждать не приходится.ГЫ!!! - а что же он с ими сделал?......

Хихихи......Такое впечатление, что откат тразакции - это такая операция, уууу какая большая и сложная :).
22 янв 04, 17:05    [503215]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 ЛП

Вы совершенно правы, Access АЦТОЙ и ссылки на (кстати уважаемого мной) Дейта его не спасают. Патамушта, в случае падения он сделает не commit и не rollback, а элементарно нарушит логическую (а возможно и физическую) целостность базы данных. По моему это ОЧЕНЬ плохо. Я пошел домой, по этой причине свое участие в сей дивной дискуссии заканчиваю.

Ничего личного
22 янв 04, 17:12    [503228]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Мимо пробегал....:)
Guest
А у меня на акцессе 20 чел база - 100 Мб, склады, заказы, динамические прайс-листы, заказчики, накладные и т.п. - в общем целая контора(кроме бух. учета) с обротом в десятки млн.евро работает. И транзакции там есть, а на тормоза нткто не жалуется. Я понимаю, что клиент-сервер лучше, и сейчас хочу на него переходить, но не потому, что Акцесс плох. В течении 5 лет он полностью всех удовлетворял. Просто выросли мы из него.... Но раньше это был оптимальный вариант.
22 янв 04, 17:13    [503236]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Глюк
в случае падения он сделает не commit и не rollback, а элементарно нарушит логическую (а возможно и физическую) целостность базы данных.
Вот именно это я и имел в виду, когда говорил про "ни ухом ни рылом в аксесе".
Ничего личного

2 мимо пробегал
Ну а у меня 100-150 человек база 300метров в центральном офисе. И тоже никто чугуниевых тормозов не наблюдает
За 2 года ни одного случая "нарушения логической целостности данных"
22 янв 04, 17:24    [503254]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
автор
А что он по твоему сделает? Commit?

Вполне возможно нарушение данных, о чем тебе писали. То что у тебя это не встречалось - очень хорошо, у меня было, очень редко, но было.

Что касается устойчивости к сбоям - последняя буква в ACID, говорит именно об этом. Открываем MSDN и читаем (Using Transactions):

Durable denotes that after a transaction is committed, its updates survive — even if there is a subsequent system crash.

И далее:

Important File-server databases, such as the Jet database engine, can't guarantee durable transactions. There are currently no file-server—based database engines that can fully support this criterion of true transactions. For example, a database connected to a file server can't be expected to fully support the durability rule if the file server crashes before a transaction has had time to commit its changes. If you require true transaction support with respect to durability, you should investigate the use of a client/server database engine such as SQL Server or the Microsoft Data Engine (MSDE).
22 янв 04, 18:14    [503354]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
ЛП
Не вижу предпосылок для такого утверждения.


Я попробовал.

ЛП
Почему нельзя сделать встроенное в аксес средсво для бекапа, или почему для бекапа надо открывать базу монопольно - мне пока непонятно.


Потому что данные (если речь о сетевой версии) обрабатываются не централизованно.
22 янв 04, 18:18    [503363]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 IgorM
По поводу бекапа - возражений нет. Понял, закопался на два метра :)

Это был кусок, по которому нет возражений. Теперь возражения:

По поводу транзакций.
Копирую цитату из MSDN
For example, a database connected to a file server can't be expected to fully support the durability rule if the file server crashes before a transaction has had time to commit its changes.
Какое накуй Durability если сервер crashes before??? Вы млять о чем? С Лукоморья приехали? Где дуб рухнул?
Выкинь нафих такой MSDN, я тебе новый подарю. Читай больше классиков (того же Дейта)

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

у меня было, очень редко, но было.
Что именно? Транзакция не сработала? Т.е. 1) начал транзакцию 2) добавил запись 3) закоммитил транзакцию 4) посмотрел - а записи зуй? И при этом база жива и здорова? Не верю. Не читай сказки на ночь.
(если еще раз подтвердишь, что так оно и было - может и поверю, чудеса таки бывают)
22 янв 04, 22:24    [503603]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить