|
|
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Интересно насколько масштабируемо решение Сиквел+ADP.Видел ли кто нибудь крупный рабочий комплекс (80-150 интенсивно работающих пользователей и размер базы от 50 гигабайт). Вопрос о том,насколько эфективен будет клиент по сравнению с другими (ODBC и пр.) Какие подводные камни при такой реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 13:19 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Видел, сам работаю (около 300 пользователей). Насколько эффективен - если логика вся на сервере, то эффективен. Из подводных камней - тупость аксесав некоторых моментах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 15:21 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Тупость только в некоторых моментах, просто не до конца написал. Дело в том, что аксес при конекте выгребает кучу нужной ему информации о таблицых, вьюхах и ещё много чего. Ещё периодически валится на выборке большого количества данных в форму. Хранимая работает быстро на серваке - а аксес не принимает данные. Если с условиями ту же хранимую, то всё нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 15:26 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Если проэкт большой не только по числу юзеров но и по функционалу , то на Access начнеш быстро, но потом дорабатывать и сопровождать запаришся. Но это не беда. У нас например клиент полиморфный - часть на AccessMDB, часть на AccessADP часть на VB часть на C# ASP Каждый по своему хорош Если есть возможность выбора , то этетически мне ближе C# AccessADP неплох если нужен быстрый старт с резким набором функционала (этакий рабочий(и работающий) протатип ), но затем нужен переход на платформу с нормальной поддержкой ООП иначе в конце будет каша неудобоваримая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 15:58 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
ну тогда самый оптимальный вариант ассембер - всё будет в тыоих руках.... главное что нужно получить от проги если ввод - акса + SQL за глаза, а ежели какихто общетов - в SQL можно присабачить расширенные процедуры хоть на чем и вперед. тоже самое можно сделать и для клиентской части. а связь аксом-SQL отличный вариат для выборки данных для клиента. на аксе можно писать великолептных клиентов. главное правильно распределить ввыплняемые задачи. Хранимая работает быстро на серваке - а аксес не принимает данные. Если с условиями ту же хранимую, то всё нормально. на фига гнать на клиента столько данных? что оператор сможет визуально их обработать? нада правильно сформировать данные хранимкой и их отогнать на клиента - в этом мастерство и заключается. тут был вопрос по поиску данных в отчете в 200 страниц!!! грамотнее было-бы формировать отчет в одну страницу, но с нужными данными распечатать(подготовить на печать) 200 страниц - а потом их анализировать? а комп зачем? - пишмашка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 19:55 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Масштабируемость это дело SQL сервера. Но коммерческий проект я бы на adp разрабатывать не взялся - см. посты Hummer за минусом постов вадя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 21:01 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Из подводных камней - тупость аксесав некоторых моментах хотелось бы знать кто и что считает тупостью акса. ваши мниния , господа! моё - нужно городить выделение строки цветом.(хотя и решается просто) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2003, 17:51 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Я бы не стал категорично применять слово тупость . Выражаюсь более мягко - негибкость . Вот обьеденить бы 3 продукта: Paradox (Corel, borland, может еще куому-то сплавят), Sybase Power Builder и Access! У каждого из них есть такие изюминки, которые влюбляют раз и надолго. надо только просечь. Так вот - жесткая привязка проекта adp к конкретному SQL серверу - это похороны сверхперспективного продукта. Если разработчики не одумаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2003, 18:23 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2 Pavel Масштабируемость это дело SQL сервера. Но коммерческий проект я бы на adp разрабатывать не взялся Все таки можно поподробнее - почему? Я как раз взялся за разработку почти с нуля достаточно крупного проекта, причем часть его уже крутится у клиента на 1С. Переписывать будем все. Неужели это более тормозной и неправильный путь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2003, 10:03 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Мля... Псиал-писал, в итоге прервалось соединение. Писать устал - поэтому выборка основных тезисов: 1) Все зависит от сервера и только от сервера. 2) Руки кривые - на Микрософт не пеняй. 3) 200 страниц отчета и поиск нужной - в морг 4) "Разруха прежде всего в головах..." (с) Булгаков ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2003, 14:56 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2Тёмный ну ты просто гений.... 2Odess пиши на том что, знаешь и то что нравится. лично мне нравиться очень система команд PDP11(кто помнит, тот знает) и ассемблер к ней.... я бы сделал проект на ADP+SQL2000. - API подключать можно (без особых проблем). расширенные процедуры (на клиенте и на сервере(повторяюсь)) хоть на чем. вариант RUNTIME (ADE) почти exe. полный комплект мелкосовтовких примочек(типа офиса) - это по происхождению. описалово есть приличное. самое главное чтоб голова была. и если писать командой - так чтоб народ был умеющий работать в команде.(а это большая редкость. из практики) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2003, 16:38 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Писал довольно давно проект на ADP. Действительно, очень быстро растет функционал на Accesse. Со временем, когда размер ADP файла после сжатия стал более 10M, и я запарился с падениями Access, стал выносить оттуда классы в VB, и делать COM-библиотеки - разгрузил более 60% кода, да и работать все стало в 2 раза быстрее. Часть критичных к быстродействию классов потом была еще переписана на С++, и получил весьма адекватное по быстродействию приложение. Далее. Действительно, грид на Access не позволяет по-человечески изворачиваться с раскраской, колонками-картинками, выпадающими календариками ипрочими прелестями. Но это не страшно, т.к. такое требуется дай бог в 15% всех гридов в приложении. Поэтому постепенно, уже в процессе отладки некоторые формы со вложенным гридом были переписанны с использованием Infragistics UltraGrid (очень похож внешне на Access-овский, поэтому вписывается весьма органично). Это, плюс повсеместное использование иерархических справочников и собственного ActiveX элемента-дерева, который понимает 3 вида организации иерархии без единой строчки кода, плюс ресайз практически всех форм, дало приложению вполне профессиональный вид и функционал. (а отчеты делать в Access - вообще песня!) Так что, большие и серьезные проекты на Access делать можно и нужно, особенно в условиях нехватки разработчиков. Для сравнения на аналогичный проект полностью на С# потребуется в 3 раза больше народу, это - по-минимуму. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2003, 22:56 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Odess Все таки можно поподробнее - почему? Да хотя бы потому, что adp требует Public на сервере. А это серьезная угроза безопасности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 06:44 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
вадя писал:на фига гнать на клиента столько данных? что оператор сможет визуально их обработать? нада правильно сформировать данные хранимкой и их отогнать на клиента - в этом мастерство и заключается. Это отчёт с различными показателями всего за МЕСЯЦ. Просто количество обрабатываемых в ДЕНЬ записей очень велико - порядка 1,5 млн. записей. Разумеется, все записи не требуются - цифра приведена для того, чтобы было понятно, каков объём данных. Данные группируются по определённым критериям и выводятся не в отчёт, а на форму. Мастера есть, не сумлевайтесь:) 2 Pavel Ну с тупостью погорячился, просто некоторые моменты в поведении аксеса крайне поражают:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 09:19 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2Hummer >просто некоторые моменты в поведении аксеса крайне поражают:) Спорю на банан - нет такой системы в которой что-нибудь да как-нибудь не поразило разработчика (правда, Акес иногда поражает на смерть ) == Через терни - к зведам :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 09:24 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2 Pavel Да хотя бы потому, что adp требует Public на сервере. А это серьезная угроза безопасности. Что требует ? Поясни для бестолкового ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 10:16 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Public - это стандартная роль MSSQL. Позволяет много такого, что позволять не надо бы. В небольшом и некоммерческом проекте на это можно забить. А вот для коммерческого проекта это никуда не годится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 11:41 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Интересно насколько масштабируемо решение Сиквел+ADP.Видел ли кто нибудь крупный рабочий комплекс (80-150 интенсивно работающих пользователей и размер базы от 50 гигабайт). Вопрос о том,насколько эфективен будет клиент по сравнению с другими (ODBC и пр.) Какие подводные камни при такой реализации. Есть рабочий проект. Есть работа с одним сервером БД другого офиса по выделеному каналу. Пользователей порядка 100. База до 10 Гб (пока ). Все работает. Не скажу летает, но серьезных сбоев и задержек не наблюдается. По сравнению с ODBC - однозначно лучше...имхо. Другие варианты не пробовал, пока и этот устраивает. Возможно и нужно будет переходить на другие платформы, но при грамотном написании серверной и клиентской части запас масштабируемости довольно большой. P.S. Совсем недавний пример грамотного написания: была форма сбора статистической информации, переписал по-другому хранимую процедуру, и немного форму, время работы изменилось с 10-20 сек до 1-3 сек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 11:55 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2 Pavel Public - это стандартная роль MSSQL. Позволяет много такого, что позволять не надо бы. В небольшом и некоммерческом проекте на это можно забить. А вот для коммерческого проекта это никуда не годится. Бедный MSSQL. И ничего-то коммерческого на нем не напишешь, так поиграться только :) Напиши это в конфу по MSSQL :) А в аксессе есть стандартная группа Users, куда тоже попадают все пользователи базы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 14:47 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Могу сказать про свое негативное впечатление об ADP/ADE. Многое касается только крупных проектов. 1. То что ADE часто валится без всяких на то причин и имеет неприличный размер, к этому думаю все привыкли. Под валится, имею в виду не создается ADE 2. Объекты внутри часто, просто херятся, даже эспортнуть нельзя, без опять-таки видимых причин. 3. Компилятор может не замечать ошибок, ну это ладно, мелочи жизни. 4. Очень хреново работать с ActiveX-контролами. Блин, даже свойства не отображаются нормально. Список свойств и методов недоступен при нажатии на точку. Приходится что-то делать сначала на VB6, а потом переносить код в Access, а потом иногда еще и править из-за некоторой несовместимости. 5. Некоторые ActiveX-контролами в Access глючат, некоторые выдают ошибки, такие, что работать с ними просто невозможно. 6. Из-за привычки ADE самохериться приходится создавать головной ADE, который имеет ссылки на остальные, запускать это можно только 1 раз (типа не dll:-), если меняется что-то в подчиненных ADE приходится пересоздавать головные. Геморрой еще тот. 7. Очень неприятная особенность при большой БД. Access скачивает себе список всех объектов БД при подключении: вьюх, таблиц, хр. процедур, функций. При большом количестве объектов на сервере такие чудные мгновения могут сильно растянуться. Если ADE имеет ссылки на другие ADE, то они при обращении к ним радостно сделают то же самое. 8. С API дружит хреново, почему у контролов нет хендлеров до сих пор непонятно. Функционал втроеных контролов оставляет желать много лучшего. 9. Ну и куча глюков о которых вспоминать нет времени, да и памяти никакой не хватит. З.Ы. Ну, а плюсы сами знаете :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 14:14 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
И все это (за искл. п.7) - кажись особенности аксеса вообще, а не именно адп/аде. 1. Неприличный размер - это сколько? Особенно в сравнении с такой же функциональностью, реализованной на VB к примеру? И "не создается ADE" - это как? Может просто беда с проектом вышла? 2. Опять таки беда с проектом? Декомпайл/восстановить/сжать никак не помогает? 3. Опять беда с проектом? Что ж это за размер такой, что он так по черному глючит? 4. Через ссылки не пробовал нужные библиотеки подключать? И явно тип описывать? У меня так еще в 97-м (мдб разумеется) все доступно и через точку все что нужно вываливается. 5. Есть такое. Так ведь контролы глючат, а не аксес. Хотя... кто ж его знает... 6. Если меняется что-то в библиотечных ade - ни фига не надо пересоздавать головной. Разумеется если интерфейсы не изменялись. 7. Ну есть такое, есть... 8. Хендлеров нет - потому что аксесовский контрол (не в фокусе) ни фига и не окно. Откуда ж там хендлеру взяться? Экселевские ячейки тоже без хендлеров, но это вроде как и не мешает. 9. См. п.7 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 14:34 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2Лох Позорный полностью подписываюсь под тем что ты ответил. полностью подписываюсь под тем что ты ответил. полностью подписываюсь под тем что ты ответил. полностью подписываюсь под тем что ты ответил. !!!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 16:17 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
автор писал:И все это (за искл. п.7) - кажись особенности аксеса вообще, а не именно адп/аде Однако утешает это мало :-) автор писал:1. Неприличный размер - это сколько? Особенно в сравнении с такой же функциональностью, реализованной на VB к примеру? И "не создается ADE" - это как? Может просто беда с проектом вышла? Да по разному бывает. Бывает и создается, а некоторые формы отказываются работать. Размер может быть метров под 20. Глюки накапливаются каким-то образом, сравнивать с VB, думаю, не коректно, хотябы потому, что VB создает exe-ик каждый раз заново. А решение проблем - восстановление из BackUp :-) автор писал:4. Через ссылки не пробовал нужные библиотеки подключать? И явно тип описывать? У меня так еще в 97-м (мдб разумеется) все доступно и через точку все что нужно вываливается. Когда на форму кидаешь ActiveX, он и так в референсах прописывается. Если его объявить, например, как Код: plaintext автор писал:5. Есть такое. Так ведь контролы глючат, а не аксес. Хотя... кто ж его знает... В VB-то пашут, значит Access глючит. автор писал:6. Если меняется что-то в библиотечных ade - ни фига не надо пересоздавать головной. Разумеется если интерфейсы не изменялись. Надо, хоть букву одну измени и вперед, пересоздавать головной ADE! автор писал:8. Хендлеров нет - потому что аксесовский контрол (не в фокусе) ни фига и не окно. Откуда ж там хендлеру взяться? Экселевские ячейки тоже без хендлеров, но это вроде как и не мешает. Кто значит не окно? В какой не в фокусе? В виднах все, что есть окна. Я даже их хендлеры могу узнать (естественно не от Access'а). Только использовать это не получается. А в принципе на некрупных проектах и не крупных базах, ADE очень неплох. Про MDB можно спокойно забыть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 18:06 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Да, чего собственно зашел-то :-) Хотел узнать можно ли программно создать ADE? Если нет, вот вам еще один минус :-) В 97-м была недокументированная функция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 18:16 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32304489&tid=1678427]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
92ms |
get tp. blocked users: |
2ms |
| others: | 213ms |
| total: | 395ms |

| 0 / 0 |
