 | | 16.11.2020 1С:Салон красоты - выпуск редакции 3.0 на платформе "1С:Предприятие 8.3", изменение цен и ассортимента
Фирма "1С" объявляет о выпуске редакции 3.0 конфигурации "Салон красоты" - совместного решения фирмы "1С" и Центра Разработки "Лаборатория
программного обеспечения" (компания "Хеликс").
|
| | 06.02.2020 Выпущен новый релиз программного продукта "1С:Медицина. Стоматологическая клиника"
Номер релиза 1.0.39.3. В релизе обновлена библиотека МДЛП. |
| | 15.11.2019 Выпущен новый релиз программного продукта "1С:Медицина. Стоматологическая клиника"
Номер релиза 1.0.38.4. В релизе исправлены обнаруженные ошибки, обновлена библиотека МДЛП. |
| | 28.03.2019 Выпущен новый релиз программного продукта "1С:Салон красоты"
Номер релиза 2.0.35.1. В релизе добавлено внешнее торговое оборудование, исправлены обнаруженные ошибки. |
| | 29.12.2018 Выпущен новый релиз программного продукта "1С:Фитнес клуб КОРП", ред.4.0
Номер релиза 4.0.10.5. В релизе реализована поддержка ставок НДС 20%, 20/120. |
|
|
|
|
|
|
 |
|
|
|
Что может привести к необходимости свертки базы? Обычно с ростом объема базы данных падения производительности при оперативной работе быть не должно. Но если такое падение наблюдается, то это - признак неоптимальной работы запросов. Если производительность оперативной работы в системе зависит от количества записей, в какой либо из таблиц, то это – ошибка проектирования или кодирования системы. Эта ошибка должна быть устранена. Лечить симптом путем свертки базы, оставив без внимания саму проблему кажется нам совершенно неправильным. В этом случае следует оптимизировать запросы и исправлять ошибки проектирования, а не разбивать одну базу на несколько.
Однако, существует ряд случаев когда необходимо сворачивать базу.
- рост объема информационной базы может сказаться на времени выполнения регламентных операций, таких как обновление статистик, бэкап и т.п. Если время выполнения регламентных операций становится неприемлемым, то следует разбивать базу.
- Еще одной причиной для разбиения одной базы на несколько может быть недостаток дискового пространства. Иначе говоря, критерием для разбиения одной базы на несколько является не объем базы (тут никаких ограничений нет), а требования бизнес-процессов конкретного внедрения.
- Как только начинает не устраивать производительность и после анализа ситуации видно, что дело нельзя решить другими изместными способами.
- Как только база вырастает до объемов, препятствующих удобному резервному копированию, реиндексации, обновлению конфигурации и пр.
Без быстрой дисковой подсистемы старайтесь, чтобы хотя бы половина объема базы умещалась в оперативной памяти, ибо если индексы таблицы бухитогов например в памяти не умещаются и начинают в подкачку с диска, то производительность падает как раз из-за размера базы, даже точнее некоторых больших ее таблиц. Для базы размеров 30 Gb рекомендуется RAM 16Gb и более.
|
|
 |
Вход для клиентов |  |
|
