(044) 455-03-55
e-mail: info@assoft.com.ua

Каталог програмної продукції

В цьому розділі Ви знайдете інформацію про найбільш популярних галузевих і спеціалізованих рішення. Рішення, що відповідають потребам в автоматизації найбільш важливих для підприємств бізнес-процесів. Які також дозволяють зменшити витрати споживачів при впровадженні за рахунок поставки в якості готових рішень.

Розрахунок вартості програмних продуктів

Тут Ви можете зробити попередній розрахунок вартості необхідного комплекту програмних продуктів. Зробити це ви можете, вибравши потрібну Вам програму, вказавши необхідність апгрейда, потрібну кількість робочих місць і режим роботи бази даних (файловий / клієнт-сервер). * Знижка на апгрейд ісчесляется з урахуванням різниці між необхідною і вже наявної у Вас програмою, не більше 50% від вартості набуває комплекту ПП.

Порівняння програмної продукції

Тут Ви можете порівняти основні функціональні можливості прикладних рішень, призначених для автоматизації типових завдань обліку та управління підприємств. При розробці цих програмних продуктів враховувалися як сучасні міжнародні стандарти управління (ERP, ERP II, MRP II, CRM, SCM, і ін.), Так і реальні завдання українських підприємств.

Автоматизація "Під ключ"

Ми готові надати повний комплекс послуг по автоматизації обліку на Вашому підприємстві. Фахівці нашої компанії допоможуть вибрати оптимальну програмну продукцію, здійснити поставку і установку, налаштувати, адаптувати систему під специфіку діяльності і підібрати варіанти підтримки.


Чому SQL "гальмує"?

Дата: 6-06-2018, 15:31

Отже, перше, що необхідно зрозуміти і запам'ятати: SQL-системи не призначені для прискорення виконання вибірок і друку звітів. Якщо Ви очікуєте, що встановивши "-торгівлю для SQL" Ви прискорите роботу своєї системи, то Ви глибоко помиляєтеся. Чи не буде вона працювати швидше. Тому будь-які розмови про те, що "... SQL-Торгівля - це гальмо ..." абсолютно не мають сенсу. Кілька років тому журнал PC Magazine проводив порівняльний аналіз (в тому числі і по швидкодії) систем управління базами даних, побудованих на основі звичайних файл серверів і з використанням клієнт-серверних (SQL) систем. Природно, умови випробувань по можливості були нівельовані, тобто застосовувалися однакові обсяги баз даних, однакові їх структури, один і той же комп'ютер в якості сервера, однакову кількість робочих станцій і т.д. Якщо мені не зраджує пам'ять, з клієнт-серверних систем були випробувані Oracle, Interbase, Informix, Gupta і найдешевший в той час Watcom SQL Server. У всіх випадках, середня швидкість виконання запитів в SQL-системах була нижче, ніж у файл-серверної системи (зараз про це ефекті можна прочитати в будь-якій серйозній книзі по SQL). Випробувачі не були здивовані отриманим ефектом, оскільки були людьми грамотними і розуміли причину такої поведінки SQL-систем при заданих умовах експерименту. Адже завданням експерименту було порівняння швидкодії двох видів систем і тому були обрані умови, що дозволяють зробити це порівняння. Зокрема для тестів використовувалися бази даних об'ємом 1.5-2Гб. Адже якби дослідники взялися проводити випробування, використовуючи бази даних на порядок більшого розміру, то їм просто нема з чим було б порівнювати SQL-варіанти, оскільки звичайна файл-серверна система на таких обсягах інформації просто заткнулася б. Ось в цьому й полягає основна відмінність і перевага клієнт-серверних систем: вони будуть працювати з цілком прийнятною швидкістю з базами даних такого обсягу, з якими файл-серверна система працювати просто не зможе ( "не зможе" в тому сенсі, що її функціональність , в тому числі і швидкодія, стануть неприйнятними для комерційних додатків). 


Подивіться на звичайний мережевий варіант "1С:Підприємство: Підприємство - Торгівлю". Вона реалізована на файл-серверному принципі, тобто обробка даних ведеться робочою станцією, а сервер служить просто як додатковий, доступне всім користувачам дисковий пристрій. Це означає, що при виконанні завдання (наприклад при складанні звіту) ВСЯ база даних (або значна її частина) прокачується по мережі на робочу станцію і там обробляється процесором робочої станції. Швидкодія такої системи залежить від швидкодії диска сервера, швидкості передачі даних по мережі, потужності процесора робочої станції, обсягу її ОЗУ і деяких інших чинників. Центральний процесор сервера грає другорядну роль і повинен просто забезпечувати передачу потоку даних з мережевого каналу на диск і назад, по можливості не вносячи уповільнення в цей процес. Головним в такому підході є те, що практично вся база даних переганяється по мережі на робочу станцію для подальшої обробки. Якщо кілька станцій одночасно виконують збірку звітів, то всім їм закачується база даних і природно система "гальмує". Коли виконуються менш накладні операції, типу введення нового документа, то обсяг перекачування даних значно менше, правда в реальності введення документа як правило супроводжується пошуком клієнта в довіднику, обчисленням заборгованості клієнта і т.п., що в свою чергу породжує перекачування великої кількості інформації з диска сервера на робочу станцію. Не слід також забувати про необхідність синхронізації доступу робочих станцій до даних. Оскільки вся обробка ведеться на рівні робочих станцій, а файл-сервер просто грає роль розділяється дискового пристрою, завдання синхронізації вирішуються в таких системах за допомогою організації різних файлів блокувань (на диску файл-сервера) в які кожна робоча станція записує інформацію про дані, які вона модифікує в даний момент, а при спробі вважати дані перевіряє чи не зайняті ці дані іншого робочою станцією. Незважаючи на ряд недоліків ( "висячі" блокування при аварійному вимкненні робочих станцій, "гальмування" всієї системи при модифікації великого числа записів), спосіб цілком працездатний.


Швидкість роботи такої системи прямо пов'язана з обсягом оброблюваної бази даних. Вони починають відчутно "гальмувати", коли база даних досягає обсягу понад 200-300Мб і при наближенні до 1Гб практично просто перестає працювати. Цифри звичайно приблизні і залежать від використовуваного програмного забезпечення і формату бази даних. Наприклад, при використанні формату таблиць бази даних Paradox гальмування настає значно пізніше, ніж при використанні формату DBase. Коли "гальмування" відчутно дається взнаки, користувачі системи йдуть на різні хитрощі: закривають стару базу і відкривають нову кожен квартал, намагаються видалити старі дані і т.п. Однак будь-який бухгалтер скаже Вам, що дані потрібні йому не за квартал, а мінімум за рік і переважно в динаміці, а не у вигляді окремих шматків. Та й борги клієнтів іноді тягнуться роками. Тимчасовим вирішенням проблеми в такій ситуації може бути збільшення пропускної здатності мережі за рахунок установки 100-мегабитной мережі замість 10-мегабитной і інтелектуальних маршрутизаторів замість тупих хабів. Однак, маршрутизатори надзвичайно дороги, а 100Мбит мережу дасть підвищення пропускної спроможності 2.5-3 рази (а не в 10 разів, як можна було б очікувати !!!). Та й навіщо збільшувати пропускну здатність мережі, якщо жорсткий диск сервера вже працює на межі своєї продуктивності? Через пів-року Ваша база даних виросте ще на 300-500Мб і система знову заткнеться, пустивши за вітром всі вкладені в модернізацію грошики. Не слід забувати і ще про одну значною деталі. Це архівування. Спробуйте заархівувати базу даних обсягом 1-1.5Гб - за час, що потрібне для архівації ви можете встигнути пообідати, подивитися кіно і посваритися з начальником. А адже це потрібно робити щодня. І при цьому під час архівування жоден з користувачів з базою працювати не може.


Тепер розглянемо SQL-систему (тобто клієнт-серверну систему). Якщо хтось говорить Вам, що у нього сильно гальмує SQL - запитаєте його, який у нього сервер. Якщо він відповість, щось на кшталт: "... Pentium 266, 64Мб ОЗУ і UDMA IDE", то можете сміливо сказати йому, що він ... не надто кваліфікований фахівець. Сервери для SQL-систем повинні мати значно більші ресурси. PentiumII 300Mhz з 128Мб ОЗУ і Ultra Wide SCSI дисками - це мабуть той мінімум, на якому може НОРМАЛЬНО функціонувати програмне забезпечення MS SQL Server з 5-8 підключеними клієнтами. Зауважте при цьому, що мережа з пропускною здатністю 100 Мбіт зовсім не обов'язкова. Вся справа в тому, що при роботі з SQL-сервером робоча станція не качає базу даних до себе по мережі. Вона просто передає по мережі досить компактний запит на сервер, який виконує запит, наприклад виробляє вибірку, і передає результат запиту назад на робочу станцію. Таким чином, трафік по мережі значно знижується, оскільки перекачування бази не відбувається, а по мережі передаються тільки запити і результати їх виконання. Звичайно, якщо при розробці клієнтської частини програмного забезпечення буде допущена помилка і буде запрограмований запит, результатом виконання якого є вся база даних або значна її частина, то вся ця інформація буде гойдатися на робочу станцію, яка видала такий запит. Але це вже здебільшого лежить на совісті розробників прикладних задач, тобто стосовно до програм - на совісті тих, хто займається настройками (і на совісті розробників з - в частині заборони оптимізації таких запитів).


Тепер подивимося, що ж відбувається з сервером в SQL-системі. Адже північ сам виконує отриманий запит, тому, легко уявити собі, що якщо з SQL-системою працюють 10 користувачів, то для сервера це практично те ж саме, як якщо б на ньому були одночасно запущені 10 примірників програми, з якою працюють користувачі (наприклад 10 локальних копій 1С:Підприємство-Торгівлі). Спробуйте запустити локально на якомусь Pentium 200 або 266 десять примірників -торгівлю і виконати одночасно 10 звітів про залишки на складі. Зробивши це і оцінивши результат Ви зрозумієте, що будь-які розмови про "гальмуванні" SQL-системи без обговорення параметрів сервера не мають сенсу. SQL-системи вкрай ненажерливі на ресурси сервера. По-хорошому для таких систем взагалі слід використовувати комп'ютери з RISC процесорами в многопроцессорном варіанті (що-небудь з продукції SUN Microsystems). Однак, для наших бідних клієнтів з їх обмеженими фінансовими можливостями SQL-системи все одно мають суттєву перевагу: навіть при використанні сервера вартістю 4-5 тис. Доларів вони будуть працювати з цілком прийнятною швидкістю з базами даних такого обсягу, на якому звичайні файл-серверні системи просто замовкнуть. Причому, цей обсяг може досягати величин в десятки ГІГАБАЙТ. Адже доступ до даних дуже швидкий - вони розташовані тут же, на диску сервера і не вимагають передачі по мережі для подальшої обробки. Всі запити надходять до сервера, так що крім звичайного файлового кешування є величезні можливості по оптимізації виконання запитів, їх распараллеливанию. Ці можливості вже закладені в програмне забезпечення MS SQL Server, а від розробників з потрібно так написати виконуючу частина програми, щоб використовувати ці можливості в повній мірі. Можливо також застосування різних хитрощів, наприклад серверів-реплікаторів (для поділу груп користувачів на тих, хто користується тільки звітами, тобто працює в режимі "тільки читання", і тих, хто активно модифікує дані) або рознесення даних за різними дисковим пристроїв. При перевантаженні дискової системи вона легко модернізується, наприклад за допомогою RAID-масиву (не забувайте однак, що SQL-система - це взагалі інша цінова категорія як за ціною матобеспеченія, так і за ціною заліза). В результаті при правильному проектуванні системи (якщо не будуть виявлені любителі видавати круті запити, результатом яких буде перекачування всієї бази даних по мережі), 100 Мбіт-ва мережа може не знадобитися. Ось що в першу чергу дає SQL-система. Взагалі, SQL-система надає значні можливості для оптимізації апаратної частини і налаштування програмної частини. І говорити про "гальмуванні" SQL-системи має сенс тільки тоді, коли ці можливості вичерпані.

До сих пір ми говорили про принципові відмінності файл-серверних систем від клієнт-серверних. Тепер трохи про додаткові переваги клієнт-сервера.


Надійність. Клієнт-серверні системи мають вбудований механізм роботи з транзакціями, в тому числі і їх відкату. У файл-серверних версіях програм також є механізм роботи з транзакціями, проте спосіб реалізації їх принципово відрізняється. У файл-серверних версіях механізм транзакцій є ні що інше, як просто блокування всієї бази даних до завершення виконання критичних по часу операцій однією з робочих станцій. Відкат можливий тільки при збереженні працездатності робочої станції, яка ініціювала транзакцію. У клієнт-серверної системи цей механізм (який реалізується програмним забезпеченням SQL-сервера - в нашому випадку MS SQL Server 6.5) значно складніший. Він дозволяє отримати "зліпок" бази даних на момент початку транзакції без блокування бази даних. І зліпків таких може бути багато: для кожної робочої станції - свій. У разі "зависання" робочої станції, яка відкрила транзакцію, транзакція може бути просто відкинуті (тобто база даних буде відновлена ​​в тому вигляді, в якому вона була до початку ініціації транзакції). Відкат здійснюється або за запитом робочої станції (при збереженні її працездатності), або при перезавантаженні робочої станції, або адміністратором SQL-системи. Таким чином, вихід з ладу робочої станції не настільки небезпечний для цілісності бази даних. Крім того, SQL-система веде так званий журнал транзакцій. По суті база даних зберігається у вигляді її початкового вмісту і її модифікацій записаних в журнал транзакцій. Такий спосіб зберігання дозволяє виробляти архівування бази даних під час роботи всієї системи: просто стан бази даних фіксується на момент початку архівування, відсікаються незавершені транзакції, а основна база і частина журналу транзакцій, що містить завершення транзакції записуються в архів. Процес архівування легко піддається автоматизації, тобто присутність оператора необов'язково - SQL-сервер має вбудовані засоби для цього.


Захист. В общем-то захищеність даних в значній мірі залежить від прикладної задачі (1С:Підприємство-Торгівлі або 1С:Підприємство-Розрахунку), проте в порівнянні зі звичайним варіантом, в якому будь-який початківець хакер спокійно може зрубати пароль, в клієнт-серверному варіанті захист даних спирається на засоби , що надаються SQL-сервером, що набагато більш недежно.


Гнучкість застосування. Системи на основі SQL-сервера дозволяють побудувати складні мережеві конфігурації з багатьма десятками і навіть сотнями користувачів. При цьому розробнику надаються широкі можливості по оптимізації системи, її поділу по групах складності і способам доступу. Сервери-станції, наприклад, дають прекрасний механізм для організації системи обліку у великій організації з розгалуженою системою віддалених офісів, складів і т.п. При цьому, робота на такій системі може вестися в реальному режимі часу, без перерв для перенесення і синхронізації даних - досить лише організувати постійні канали зв'язку 32-128 Кбіт, що цілком здійсненно на наших телефонних лініях і не дуже дорого (звичайно, в масштабі великої компанії).


Ну і нарешті настав час поговорити про недоліки. Недоліків у SQL-систем багато - і великих і дрібних - тих же самих, які притаманні і файл-серверних систем. Однак є два і вельми істотних.


Перший Ви наочно побачите в прайсі фірми - це ціна. Ціна не тільки програмного забезпечення, але і ціна заліза на якому воно може функціонувати і ціна обслуговування. Ну, що ж робити - SQL це продукт високих технологій. А продукт високих технологій завжди коштує дорого і повинен експлуатуватися грамотним персоналом, тому і системний адміністратор, здатний грамотно працювати з SQL-системою обійдеться дорожче, ніж аналогічний фахівець для звичайної файл-серверної системи.

Другий - це істотні недоробки клієнтської частини програм комплексу: Програмне продукція для SQL. У тих версіях, які поки випущені в продаж, далеко не повністю використовуються переваги SQL сервера. Розробник або полінувався або не встиг реалізувати в повній мірі можливості, що надаються засобами SQL сервера, тому в багатьох випадках там, де можна очікувати виконання нескладного SQL-запиту програма просто (як це робилося і в файл-серверної версії) перекачує на локальний комп'ютер всю базу даних, вірніше її частина, і потім продовжує роботу з локальною копією. Це з "внутрішньої" точки зору, а зовні, для користувача це виливається в ті самі "гальма" про яких пишуть в конференції. Залишається тільки сподіватися, що з часом фірма доопрацює свої SQL-продукти таким чином, що функціональність SQL-сервера буде використовуватися значно повніше. На виправдання фірми можу зауважити, що програмний продукт такої складності завжди розвивається поступово - адже якщо намагатися випустити на ринок повністю "вилизаний" продукт найвищої якості, то цього можна просто не дочекатися. Всі софтверні компанії, що випускають продукти високого ступеня складності йдуть саме шляхом поступового поліпшення спочатку випущеного продукту. Той, хто намагається порушити цю традицію зазвичай терпить крах на цьому шляху. Досить згадати історію з випуском Windows 95 фірмою Microsoft: випуск продукту все відтягувався і відтягувався, незважаючи на багаторазові анонси та перенесення термінів, і в кінці кінців на ринок було викинуто недопрацьований продукт. А вже потім були випущені OSR1 і OSR2, однак продукт так і стался "сирим".


Тепер пора підвести деякі разом. Не чекайте, що SQL-системи будуть працювати швидко. Але вони зможуть працювати там, де файл-серверний варіант не зможе, або ж буде створювати суттєві незручності (віддалений доступ). Однак і обійдеться це Вам не дешево.


Ось, мабуть, і все. Сподіваюся, що цей короткий огляд дозволить Вам хоч трохи зорієнтуватися в питанні, що таке SQL і навіщо він потрібен.



Вернуться

Категория: Статьи