Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / Масштабируемость связки SQL сервер+ADP / 25 сообщений из 34, страница 1 из 2
24.10.2003, 13:19
    #32304270
Самовар
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Интересно насколько масштабируемо решение Сиквел+ADP.Видел ли кто нибудь крупный рабочий комплекс (80-150 интенсивно работающих пользователей и размер базы от 50 гигабайт). Вопрос о том,насколько эфективен будет клиент по сравнению с другими (ODBC и пр.) Какие подводные камни при такой реализации.
...
Рейтинг: 0 / 0
24.10.2003, 15:21
    #32304489
Hummer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Видел, сам работаю (около 300 пользователей).
Насколько эффективен - если логика вся на сервере, то эффективен.
Из подводных камней - тупость аксесав некоторых моментах.
...
Рейтинг: 0 / 0
24.10.2003, 15:26
    #32304499
Hummer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Тупость только в некоторых моментах, просто не до конца написал. Дело в том, что аксес при конекте выгребает кучу нужной ему информации о таблицых, вьюхах и ещё много чего.
Ещё периодически валится на выборке большого количества данных в форму. Хранимая работает быстро на серваке - а аксес не принимает данные. Если с условиями ту же хранимую, то всё нормально.
...
Рейтинг: 0 / 0
24.10.2003, 15:58
    #32304556
Latuk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Если проэкт большой не только по числу юзеров но и
по функционалу , то на Access начнеш быстро,
но потом дорабатывать и сопровождать запаришся.
Но это не беда. У нас например клиент полиморфный -
часть на AccessMDB,
часть на AccessADP
часть на VB
часть на C# ASP
Каждый по своему хорош

Если есть возможность выбора , то этетически мне ближе C#
AccessADP неплох если нужен быстрый старт с резким набором функционала
(этакий рабочий(и работающий) протатип ), но затем нужен переход на
платформу с нормальной поддержкой ООП иначе в конце будет каша неудобоваримая.
...
Рейтинг: 0 / 0
24.10.2003, 19:55
    #32304864
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
ну тогда самый оптимальный вариант ассембер - всё будет в тыоих руках....

главное что нужно получить от проги если ввод - акса + SQL за глаза, а ежели какихто общетов - в SQL можно присабачить расширенные процедуры хоть на чем и вперед.
тоже самое можно сделать и для клиентской части.
а связь аксом-SQL отличный вариат для выборки данных для клиента.
на аксе можно писать великолептных клиентов.
главное правильно распределить ввыплняемые задачи.

Хранимая работает быстро на серваке - а аксес не принимает данные. Если с условиями ту же хранимую, то всё нормально.
на фига гнать на клиента столько данных? что оператор сможет визуально их обработать? нада правильно сформировать данные хранимкой и их отогнать на клиента - в этом мастерство и заключается.
тут был вопрос по поиску данных в отчете в 200 страниц!!!
грамотнее было-бы формировать отчет в одну страницу, но с нужными данными
распечатать(подготовить на печать) 200 страниц - а потом их анализировать? а комп зачем? - пишмашка?
...
Рейтинг: 0 / 0
24.10.2003, 21:01
    #32304905
Pavel
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Масштабируемость это дело SQL сервера. Но коммерческий проект я бы на adp разрабатывать не взялся - см. посты Hummer за минусом постов вадя
...
Рейтинг: 0 / 0
25.10.2003, 17:51
    #32305161
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Из подводных камней - тупость аксесав некоторых моментах

хотелось бы знать кто и что считает тупостью акса.

ваши мниния , господа!

моё - нужно городить выделение строки цветом.(хотя и решается просто)
...
Рейтинг: 0 / 0
25.10.2003, 18:23
    #32305164
Pavel
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Я бы не стал категорично применять слово тупость . Выражаюсь более мягко - негибкость . Вот обьеденить бы 3 продукта: Paradox (Corel, borland, может еще куому-то сплавят), Sybase Power Builder и Access!
У каждого из них есть такие изюминки, которые влюбляют раз и надолго. надо только просечь. Так вот - жесткая привязка проекта adp к конкретному SQL серверу - это похороны сверхперспективного продукта. Если разработчики не одумаются.
...
Рейтинг: 0 / 0
26.10.2003, 10:03
    #32305323
Odess
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
2 Pavel
Масштабируемость это дело SQL сервера. Но коммерческий проект я бы на adp разрабатывать не взялся

Все таки можно поподробнее - почему? Я как раз взялся за разработку почти с нуля достаточно крупного проекта, причем часть его уже крутится у клиента на 1С. Переписывать будем все. Неужели это более тормозной и неправильный путь?
...
Рейтинг: 0 / 0
26.10.2003, 14:56
    #32305387
Темный
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Мля... Псиал-писал, в итоге прервалось соединение. Писать устал - поэтому выборка основных тезисов:
1) Все зависит от сервера и только от сервера.
2) Руки кривые - на Микрософт не пеняй.
3) 200 страниц отчета и поиск нужной - в морг
4) "Разруха прежде всего в головах..." (с) Булгаков
...
Рейтинг: 0 / 0
26.10.2003, 16:38
    #32305415
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
2Тёмный

ну ты просто гений....

2Odess
пиши на том что, знаешь и то что нравится.

лично мне нравиться очень система команд PDP11(кто помнит, тот знает)
и ассемблер к ней....
я бы сделал проект на ADP+SQL2000. - API подключать можно (без особых проблем). расширенные процедуры (на клиенте и на сервере(повторяюсь)) хоть на чем. вариант RUNTIME (ADE) почти exe. полный комплект мелкосовтовких примочек(типа офиса) - это по происхождению.
описалово есть приличное.

самое главное чтоб голова была. и если писать командой - так чтоб народ был умеющий работать в команде.(а это большая редкость. из практики)
...
Рейтинг: 0 / 0
26.10.2003, 22:56
    #32305499
vdimas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Писал довольно давно проект на ADP. Действительно, очень быстро растет функционал на Accesse. Со временем, когда размер ADP файла после сжатия стал более 10M, и я запарился с падениями Access, стал выносить оттуда классы в VB, и делать COM-библиотеки - разгрузил более 60% кода, да и работать все стало в 2 раза быстрее. Часть критичных к быстродействию классов потом была еще переписана на С++, и получил весьма адекватное по быстродействию приложение.

Далее. Действительно, грид на Access не позволяет по-человечески изворачиваться с раскраской, колонками-картинками, выпадающими календариками ипрочими прелестями. Но это не страшно, т.к. такое требуется дай бог в 15% всех гридов в приложении. Поэтому постепенно, уже в процессе отладки некоторые формы со вложенным гридом были переписанны с использованием Infragistics UltraGrid (очень похож внешне на Access-овский, поэтому вписывается весьма органично). Это, плюс повсеместное использование иерархических справочников и собственного ActiveX элемента-дерева, который понимает 3 вида организации иерархии без единой строчки кода, плюс ресайз практически всех форм, дало приложению вполне профессиональный вид и функционал. (а отчеты делать в Access - вообще песня!)

Так что, большие и серьезные проекты на Access делать можно и нужно, особенно в условиях нехватки разработчиков. Для сравнения на аналогичный проект полностью на С# потребуется в 3 раза больше народу, это - по-минимуму.
...
Рейтинг: 0 / 0
27.10.2003, 06:44
    #32305550
Pavel
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Odess
Все таки можно поподробнее - почему?
Да хотя бы потому, что adp требует Public на сервере. А это серьезная угроза безопасности.
...
Рейтинг: 0 / 0
27.10.2003, 09:19
    #32305634
Hummer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
вадя писал:на фига гнать на клиента столько данных? что оператор сможет визуально их обработать? нада правильно сформировать данные хранимкой и их отогнать на клиента - в этом мастерство и заключается.

Это отчёт с различными показателями всего за МЕСЯЦ. Просто количество обрабатываемых в ДЕНЬ записей очень велико - порядка 1,5 млн. записей.
Разумеется, все записи не требуются - цифра приведена для того, чтобы было понятно, каков объём данных. Данные группируются по определённым критериям и выводятся не в отчёт, а на форму.
Мастера есть, не сумлевайтесь:)

2 Pavel
Ну с тупостью погорячился, просто некоторые моменты в поведении аксеса крайне поражают:)
...
Рейтинг: 0 / 0
27.10.2003, 09:24
    #32305639
Senin Viktor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
2Hummer
>просто некоторые моменты в поведении аксеса крайне поражают:)

Спорю на банан - нет такой системы в которой что-нибудь да как-нибудь не поразило разработчика (правда, Акес иногда поражает на смерть )
==
Через терни - к зведам :)
...
Рейтинг: 0 / 0
27.10.2003, 10:16
    #32305701
x
x
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
2 Pavel

Да хотя бы потому, что adp требует Public на сервере. А это серьезная угроза безопасности.

Что требует ? Поясни для бестолкового
...
Рейтинг: 0 / 0
27.10.2003, 11:41
    #32305848
Pavel
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Public - это стандартная роль MSSQL. Позволяет много такого, что позволять не надо бы. В небольшом и некоммерческом проекте на это можно забить. А вот для коммерческого проекта это никуда не годится.
...
Рейтинг: 0 / 0
27.10.2003, 11:55
    #32305873
incold
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Интересно насколько масштабируемо решение Сиквел+ADP.Видел ли кто нибудь крупный рабочий комплекс (80-150 интенсивно работающих пользователей и размер базы от 50 гигабайт). Вопрос о том,насколько эфективен будет клиент по сравнению с другими (ODBC и пр.) Какие подводные камни при такой реализации.

Есть рабочий проект.
Есть работа с одним сервером БД другого офиса по выделеному каналу.
Пользователей порядка 100. База до 10 Гб (пока ).
Все работает. Не скажу летает, но серьезных сбоев и задержек не наблюдается.
По сравнению с ODBC - однозначно лучше...имхо.
Другие варианты не пробовал, пока и этот устраивает.
Возможно и нужно будет переходить на другие платформы, но при грамотном написании серверной и клиентской части запас масштабируемости довольно большой.

P.S. Совсем недавний пример грамотного написания: была форма сбора статистической информации, переписал по-другому хранимую процедуру, и немного форму, время работы изменилось с 10-20 сек до 1-3 сек.
...
Рейтинг: 0 / 0
27.10.2003, 14:47
    #32306202
x
x
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
2 Pavel

Public - это стандартная роль MSSQL. Позволяет много такого, что позволять не надо бы. В небольшом и некоммерческом проекте на это можно забить. А вот для коммерческого проекта это никуда не годится.

Бедный MSSQL. И ничего-то коммерческого на нем не напишешь, так поиграться только :)

Напиши это в конфу по MSSQL :)

А в аксессе есть стандартная группа Users, куда тоже попадают все пользователи базы :)
...
Рейтинг: 0 / 0
04.11.2003, 14:14
    #32314795
Масштабируемость связки SQL сервер+ADP
Могу сказать про свое негативное впечатление об 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. Ну и куча глюков о которых вспоминать нет времени, да и памяти никакой не хватит.

З.Ы. Ну, а плюсы сами знаете :-)
...
Рейтинг: 0 / 0
04.11.2003, 14:34
    #32314826
Лох Позорный
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
И все это (за искл. п.7) - кажись особенности аксеса вообще, а не именно адп/аде.

1. Неприличный размер - это сколько? Особенно в сравнении с такой же функциональностью, реализованной на VB к примеру?
И "не создается ADE" - это как? Может просто беда с проектом вышла?

2. Опять таки беда с проектом? Декомпайл/восстановить/сжать никак не помогает?

3. Опять беда с проектом? Что ж это за размер такой, что он так по черному глючит?

4. Через ссылки не пробовал нужные библиотеки подключать? И явно тип описывать? У меня так еще в 97-м (мдб разумеется) все доступно и через точку все что нужно вываливается.

5. Есть такое. Так ведь контролы глючат, а не аксес. Хотя... кто ж его знает...

6. Если меняется что-то в библиотечных ade - ни фига не надо пересоздавать головной. Разумеется если интерфейсы не изменялись.

7. Ну есть такое, есть...

8. Хендлеров нет - потому что аксесовский контрол (не в фокусе) ни фига и не окно. Откуда ж там хендлеру взяться? Экселевские ячейки тоже без хендлеров, но это вроде как и не мешает.

9. См. п.7
...
Рейтинг: 0 / 0
04.11.2003, 16:17
    #32315015
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
2Лох Позорный

полностью подписываюсь под тем что ты ответил.
полностью подписываюсь под тем что ты ответил.
полностью подписываюсь под тем что ты ответил.
полностью подписываюсь под тем что ты ответил.

!!!!!
...
Рейтинг: 0 / 0
04.11.2003, 18:06
    #32315243
Масштабируемость связки SQL сервер+ADP
автор писал:И все это (за искл. п.7) - кажись особенности аксеса вообще, а не именно адп/аде
Однако утешает это мало :-)

автор писал:1. Неприличный размер - это сколько? Особенно в сравнении с такой же функциональностью, реализованной на VB к примеру?
И "не создается ADE" - это как? Может просто беда с проектом вышла?
Да по разному бывает. Бывает и создается, а некоторые формы отказываются работать. Размер может быть метров под 20.
Глюки накапливаются каким-то образом, сравнивать с VB, думаю, не коректно, хотябы потому, что VB создает exe-ик каждый раз заново.
А решение проблем - восстановление из BackUp :-)

автор писал:4. Через ссылки не пробовал нужные библиотеки подключать? И явно тип описывать? У меня так еще в 97-м (мдб разумеется) все доступно и через точку все что нужно вываливается.
Когда на форму кидаешь ActiveX, он и так в референсах прописывается. Если его объявить, например, как
Код: plaintext
dim tree as TreeView
, то все видно. Но, если обращаться к имени контрола на форме, то нифига. Их эти гады не могут этого сделать который год!

автор писал:5. Есть такое. Так ведь контролы глючат, а не аксес. Хотя... кто ж его знает...
В VB-то пашут, значит Access глючит.

автор писал:6. Если меняется что-то в библиотечных ade - ни фига не надо пересоздавать головной. Разумеется если интерфейсы не изменялись. Надо, хоть букву одну измени и вперед, пересоздавать головной ADE!

автор писал:8. Хендлеров нет - потому что аксесовский контрол (не в фокусе) ни фига и не окно. Откуда ж там хендлеру взяться? Экселевские ячейки тоже без хендлеров, но это вроде как и не мешает.
Кто значит не окно? В какой не в фокусе? В виднах все, что есть окна. Я даже их хендлеры могу узнать (естественно не от Access'а). Только использовать это не получается.

А в принципе на некрупных проектах и не крупных базах, ADE очень неплох. Про MDB можно спокойно забыть.
...
Рейтинг: 0 / 0
04.11.2003, 18:16
    #32315263
Масштабируемость связки SQL сервер+ADP
Да, чего собственно зашел-то :-) Хотел узнать можно ли программно создать ADE? Если нет, вот вам еще один минус :-) В 97-м была недокументированная функция.
...
Рейтинг: 0 / 0
04.11.2003, 19:12
    #32315325
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Масштабируемость связки SQL сервер+ADP
Хотел узнать можно ли программно создать ADE


в своё время была задачка
написать прогу , которая распечатывала бы свой исходник.

а на фига?
...
Рейтинг: 0 / 0
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / Масштабируемость связки SQL сервер+ADP / 25 сообщений из 34, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]