Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
15.03.2011, 00:31
|
|||
---|---|---|---|
Насколько разумен/корректен такой код: сжатие и восстановление БД? |
|||
#18+
Есть БД, с ней работают 1) exe1.exe 2) exe2.exe БД не очень сложная, но как водится имеет свойство разрастаться, поэтому скажем так желательно ее периодически сжимать. Придумывать всякие "раз в неделю" или спец.кнопку в проге - лениво стало. Потом с БД работают больше одного exe, а в момент сжатия БД должна быть "не открыта". Придумал так: каждый раз при загрузке только exe1 , exe1 пытается ее сжать. Получится -хорошо, не получится (если вдруг exe2 запущена)-ну и бес с ним,my_JRO.CompactDatabase по ошибке перескакивает код, в другой раз м.б. получится. Насколько хороши сама идея такого подхода (на авось) и сам код? Не очень ли это безобразно все? Меня повторюсь здесь интересует СЖАТИЕ и то как я это реализовываю. Не лишний ли backup и есть ли в нем смысл? Не излишество ли сжимать БД каждый раз, пусть даже и не каждый раз это получится? Не наживу ли я лишних ошибок с таким подходом? Не рискую ли вообще потерять данные, если что не так пойдет? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59.
... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.03.2011, 00:44
|
|||
---|---|---|---|
|
|||
Насколько разумен/корректен такой код: сжатие и восстановление БД? |
|||
#18+
Не вижу смысла сжимать базу вообще. Она не имеет тенденцию разрастаться бесконечно. Очень условно говоря, если у тебя в какой-то момент данных (с индексами и пр.) на 100Мб, база будет колбаситься в районе размер 120Мб (и то, если ты интенсивно используешь удаление данных или апдейты с увеличением размера данных) за счет того, что в ней будут освобожденные и ПОКА не занятые страницы. Сжав базу ты получишь свои 100Мб, которые очень быстро вернутся к 120Мб и опять будут жить в этом размере. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.03.2011, 01:36
|
|||
---|---|---|---|
Насколько разумен/корректен такой код: сжатие и восстановление БД? |
|||
#18+
Shocker.Pro, Хочешь сказать, что вообще надо убрать этот код из основного приложения? Ну а вред от него есть? Ну можно конечно вынести в отдельную утилиту, а в help-е написать "шо делать, если хочешь сжать". Понимаешь, я уже когда-то работал "в проекте, кот. типа для внутр. пользования" с такой моделью. При таблице в 10000 записей и долбеже 10-ю процессами (каждый процесс обращается к БД скажем раз в минуту -эту минуту "работает" с одной строчкой), после суток разрастание было не плохое и торможение заметное. Там раза 4 в сутки авто-перегружал комп (Win2003! он сильно стабильнее чем XP!!!) и сжимал после перезагрузки (не тем простым кодом с JRO что счас нарыл, а каким-то более длинным -не помню-не суть) Счас у меня на тесте 1500 записей в двух осн. таблицах, размер в сжатом состоянии около 600кб (не уверен что мне нужно стремиться к 100МБ и это есть good). У среднестатистического юзера этих записей будет много меньше. Однако если пользователь решит использовать систему "по полной" типа как это делал я в примере выше (умный такой обязательно найдется), то у него будет записей поболе чем 2000. На указанных 1500 сжатие проходит мгновенно, и согласен -не больно то и нужно. Ну а если 100000 записей, с одной стороны сжимать все же нужно, а с другой - не даст ли мой код сильный тормоз в form_load. Там проблема в том еще, что приложение "сильно динамическое", параллельных процессов может быть скажем 50 (хотя это де-факто маловероятно), и тормоза точно не нужны, а при "хаотично-сформированной БД" они насколько я понимаю, таки могут иметь место быть. Т.е. мне хочется этот код-таки оставить и именно как сделал. Кроме того что "зачем ее вообще сжимать", с учетом рассуждений про долгий "form_load" при большом объеме, можно к нему придраться? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.03.2011, 01:45
|
|||
---|---|---|---|
|
|||
Насколько разумен/корректен такой код: сжатие и восстановление БД? |
|||
#18+
Дмитрий77, Как ты правильно заметил, теряем скорость загрузки. Возможно прилично (опять же учесть резервирование базы). А вот что находим - я так и не понял. Если просто "хочется" - оставляй. К коду вроде претензий нет. ЗЫ: Что-то я не понял про автоперезагруз компа, бред какой-то. Что 10к, что 100к записей и 10 пользователей - это смешные цифры даже для mdb, и если это приводило к необходимости перезагрузки компа, что-то не так было с клиентом, а отнюдь не с базой. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.03.2011, 02:35
|
|||
---|---|---|---|
Насколько разумен/корректен такой код: сжатие и восстановление БД? |
|||
#18+
>теряем скорость загрузки. Возможно прилично (опять же учесть резервирование базы). Да вряд ли мы сильно потеряем, если пара-тройка мегов. Так может и не нужно лишнее backup-копирование? Если оно и спотыкается, то только на сжатии, собственно на этом спотыке и основана идея обойти сжатие, если оно в данный момент невозможно. Впрочем если не поленюсь, проверю, благо код/debug который считает мс у меня в этот екзешник встроен. >ЗЫ: Что-то я не понял про автоперезагруз компа, бред какой-то. Не бред, там "клиенты" еще сильно грузили. Но БД кажется тоже тормозила. Но там еще таблицы часто пересчитывались через запросы+, система была сильно навороченная и "на карачиках", но при всем том уникальна в своем роде и работу делала. > а отнюдь не с базой. грузила, клиент "долго думал", пока читал запись. Но бог с ним... Таблица в самом Access по сети "долго открывалась" после утомления. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.03.2011, 03:28
|
|||
---|---|---|---|
Насколько разумен/корректен такой код: сжатие и восстановление БД? |
|||
#18+
>теряем скорость загрузки. Код: plaintext
Критично ? Если сравнивать с чтением этой же базы то время на сжатие в 3-4 раз меньше. (172+140)/93=3.35 /topic/822258&hl= Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.03.2011, 03:43
|
|||
---|---|---|---|
Насколько разумен/корректен такой код: сжатие и восстановление БД? |
|||
#18+
>Так может и не нужно лишнее backup-копирование? Убрал я про _backup.mdb Что то не припомню чтоб за 5 лет работы вышеупомянутой системы я этим когда-либо воспользовался и потерял базу, мусор только разводить. Не говоря о том, что будучи выполнена дважды даже в случае потери базы при первой итерации, после второй итерации уже ничем не поможешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.03.2011, 10:54
|
|||
---|---|---|---|
|
|||
Насколько разумен/корректен такой код: сжатие и восстановление БД? |
|||
#18+
> Автор: Дмитрий77 > >Так может и не нужно лишнее backup-копирование? > Убрал я про _backup.mdb А вот это зря. Со сжатием, я согласен с Шокером, смысла не вижу. А система бекапов должна быть обязательно, если данные в базе представляют какую-то ценность. И то что раньше все было нормально, не дает никакой гарантии что так будет и дальше. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/search_topic.php?author=%D0%BD%D1%83%D0%BD%D1%83%D0%BD%D1%83%D0%BD%D1%8322&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
35ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
others: | 776ms |
total: | 919ms |
0 / 0 |