Цитата(Rodeon @ 10.1.2013, 03:41  ) |
| Мой мнение перейти на MySQL. |
Переходи, только внемли этому совету:
| Цитата(Akina @ 10.1.2013, 09:14 ) |
| перейти на хранение картинок в файловой системе, а в БД хранить только относительные пути. |
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > База MS Access разрослась и монопольность не катит |
| Автор: Rodeon 10.1.2013, 02:41 |
| В виде эксперимента была выбрана следующая связка, как самый простой вариант: Delphi - KADAO - MS Access 1 пользователь. 1 таблица. 22 полей разных типов в таблице. 1 поле типа OLE (Картинка) в таблице. Проблема появилась после почти года пользования: 548835 записей. Размер 2 Гб (дальше наращивать не дает). Из-за большого объема базы долго запускается при первом старте. Условия: Добавления периодические, в час может и 2000-5000 новых записей появиться, а может и сутками не обновляться. Перспектива: 3-5 пользователей, желательно доступ через интернет к базе расположенной на компьютере с фиксированным IP. + Скорость. - ограничение по объему. Мой мнение перейти на MySQL. Хотелось бы услышать ваше мнение!? |
| Автор: Akina 10.1.2013, 08:14 |
| Моё мнение - перейти на хранение картинок в файловой системе, а в БД хранить только относительные пути. Либо перейти на связанные таблицы и хранение данных в MSDE, оставив Аксесс в качестве прослойки. И то, и другое можно сделать быстро и сравнительно безболезненно. Ну а потом уже спокойно переписывать всё на любой сервер БД. Кто у нас там сравнительно "родной" для Дельфи? Файрбёрд? |
| Автор: Данкинг 10.1.2013, 10:57 | ||||
Переходи, только внемли этому совету:
|
| Автор: Zloxa 10.1.2013, 11:31 | ||||||
Если внемлить совету, может статься, и прееходить не надо будет ибо MS SQL это из пушки по воробъям для:
И если уж перхеодить, при таком раскладе, то переходить определенно на чтонить бесплатное, вполне может быть даже и не на реляционное. |
| Автор: Данкинг 10.1.2013, 12:53 |
| Zloxa, ну вообще 548835 записей в MDB действительно при открытии из Дельфи тормозит. Если же база будет лежать на сетевом диске - то тем более будет медленнее. |
| Автор: Akina 10.1.2013, 12:57 | ||
Так не надо же при открытии фетчить все записи на клиента! |
| Автор: Zloxa 10.1.2013, 13:11 | ||||
+1 к каменту Акины. Если полляма фетчить с MS SQL или Oracle, тоже тупить будет. 
Зачем однопользовательской базе лежать на сетевом диске?  Тут бы можно было бы и имбидед решения посмотреть. |
| Автор: Данкинг 10.1.2013, 13:35 | ||||
Почему однопользовательской - там же "3-5 пользователей" ожидается.
Я не знаю, что за KADAO такой. Если в нём возможно не фетчить всё сразу - тогда конечно. |
| Автор: Zloxa 10.1.2013, 13:40 | ||||
точно, до ожиданий я при прочтении топикстарта не дошел 
А в обычном ADO можно?  |
| Автор: Данкинг 10.1.2013, 15:23 | ||
А где ты видел в ADO настройки фетчей? |
| Автор: Akina 10.1.2013, 15:31 | ||
Фетчей - нет... но для ADOExpress в Дельфах можно установить CursorLocation=clServerSide. Конечно, с BDE это не прокатит... Добавлено через 1 минуту и 20 секунд Впрочем, Аксесс не поддерживает динамических курсоров в принципе, вместо них (втёмную) используется keyset. |
| Автор: Zloxa 10.1.2013, 15:48 |
| Мне в этом отношении безумно нравится DOA для Oracle. Задаешь фетч буфер, если датасет скрольнет сверх него, будет дофетч. Но тут специфика оракла, думаю, не мало важный фактор. Оракл в лишь ряде случаев не умеет отдавать фетч еще до того, как запрос отработал до конца - когда сортировка, группировка должны быть применены к результирующему набору. А так вобще зачастую вобще запросы выполняются по мере фетча, если фетч все не выбрал, то и запрос до конца не выполнилсся, таблицы недосканировал, джойны не дожойнил - красота. МС, на сколько я помню, так не умеет. Курсор select * from some_table вроде как станет доступен, только после того будет произведен полный скан этой таблицы. Хотя не знаю.... forward only курсоры как в этом отношении? |
| Автор: Akina 10.1.2013, 16:20 | ||
Да точно так же как и все остальные типы... получаем выборку, потом кормим клиента. |
| Автор: Данкинг 10.1.2013, 16:36 | ||
Думаю, юзать BDE ТС в голову не придёт. |
| Автор: Rodeon 10.1.2013, 17:39 |
| DAO это другой механизм (модель) доступа к данным, вместо ADO. Брал тут http://kadao.dir.bg/ Насчет Fetch сказать не могу, не использовал. Выборку делал по условию. Пока на данный момент стоит MySQL 5.5.29.0 И как альтернатива по совету Akina: Firebird 2.5.2.26539 + Unified Interbase v2.5 C MySql до этого еще хоть как-то имел дело, FireBird в первый раз ставил (тут увидел как раз удобную вещь как Firebird 2.5 Embedded - подойдет вполне клиентам, что бы не ставить им всю серверную часть). Почему спросил мнения, потому как запросы растут и так сказать хотелось бы на будущее, что все опять заново не переделывать. |
| Автор: Akina 10.1.2013, 17:54 | ||
| Я бы всё-таки советовал MSDE. Можно даже ESQL, чтобы и правда клиентам ничего не ставить. Он даже синтаксически очень близок к Аксессу, чего про файрбёрд ну никак не сказать. А если понадобится в дальнейшем - его можно прекрасно масштабировать в полноценный промышленный MS SQL. К тому же, т.к. планируется давать к серверу доступ через Инет - безопасность должна быть не на последнем месте. А в этом вопросе сравнивать MySQL/Firebird и MSDE/MS SQL даже как-то не совсем солидно.
Ох, откажитесь от DAO, если не поздно, в пользу ADO или хотя бы RDO... гонять мегабайты через Инет - не лучшая идея, а DAO если и умеет что-то на стороне сервера, то совсем не всё и не много. |
| Автор: Rodeon 12.1.2013, 00:10 |
| Akina Ну насчет DAO я как раз на него перешел с ADO, скорость возросла и заметно, когда записей было еще примерно 300К. Насчет Microsoft SQL Server Desktop Engine нашел - изучаю. В отношении ESQL слишком много информации и очень разносторонней, если не затруднит ссылку дать, так сказать конкретизировать ваш совет! Заранее спасибо! |
| Автор: Akina 12.1.2013, 19:50 |
| http://msdn.microsoft.com/en-us/library/aa174494(v=SQL.80).aspx |
| Автор: DYUMON 12.2.2013, 08:59 |
| сжатие и восстновление делал? если будешь переходить на myslq то можешь хранить в базе картинки если их размер меньше 60кб а если больше тут тут лучше в файлах хранить и через путь брать |