Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Помогите выбрать БД и средство разработки  [new]
AlexeiAN
Member

Откуда: Москва
Сообщений: 1
Есть БД и программы, созданная на Access-2. 20 операторов и 5 БД одновременно. Работает 7 лет, иногда сбивается (приходится всех выгонять и чинить минуты 3, но иногда исчезают данные).
Надо перевести БД на MS SQL-server (якобы безсбойный) и переписать программы (Access-2 MSSQL не понимает). Начал пробовать.
Конвертирование БД Access в MSSQL-7 прошло с потерей связей (устанавливал заново), отображаются они хуже, выбор (показ) данных происходит в НЕСКОЛЬКО раз медленней, поиска данных вообще нет, и т.д; в-общем MSSQL-7 выглядит как примитивный.
Пытался выбрать средство разработки. Ни в одном (Deplhi-5, PowerBuilder-7, VisualBasic-6, FoxPro-6) нет многоколоночных combobox. В Access у меня на них построены все выборки вида: Артикул-Название-Цена-Количество, да еще со скрытыми для оператора колонками (например КодТовара), да ещё разной ширины и формата, да ещё в зависимости от других полей в форме и т.д., что в Access делается элементарно.
Подключенные к MSSQL БД все средства работают медленней раза в 1.5-2, чем Access-2 со своей БД. Кстати, Access-2000 работает медленней Access-2 раза в 3.
SQL-builder только в VB-6 позволял несложно создавать SQL-запрос (лучше чем в Acccess), у других - через ... голову.
Я ещё не ковырял создание отчетов (вложенные, сгруппированные, с отключаемыми полями и т.п., что легко делается в Access)...
Создается впечатление, что в части разработки приложений все средства выглядят как примитивные, да ещё не имеющие элементарных (с точки зрения Access-2) свойств.
Что делать?
17 янв 01, 19:42    [32034]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Павел
Guest
Давай сразу определимся: как ты коннектишся к серверу - через ODBC или через OleDB провайдер (можно из Асеss 2000 или Delphi 5.1)? Если через ОDBC то продолжать смысла нет, технология медленная и устаревшая. Если через OleDb, то будь добр, вынеси логику на сервер, и размышления по поводу скорости разных версий Ассеss'oв отпадут. А вот интерфейс у А2K тормозит сильно. И памяти просит много. А насчет примитивности MSSQL - ну я понимаю когда подобные реплики бросает сертифицированный специалист по нескольким SQL серверам (как правило Oracle или DB2 против MSSQL). А тебе могу сказать только одно: изучай продукт.
18 янв 01, 06:56    [32035]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
alvako
Member

Откуда: Тольятти
Сообщений: 39
ТО: AlexeiAN
Про клиента:
Расшифруй фразу: "нет многоколоночных combobox. В Access у меня на них построены все выборки вида: Артикул-Название-Цена-Количество, да еще со скрытыми для оператора колонками"...
Как на combobox выборка построена ? Условие выборки им задаётся? Или данные туда попадают? Или ещё как-то?
Ну нет в Deplhi-5, PowerBuilder-7, VisualBasic-6, FoxPro-6 и ещё во многих, многих продуктах...многоколоночных combobox и что ??? Всё must die, access RULEZ Forever ???
Просто, мыслишь ты в рамках аксессовской парадигмы. Нет их нигде - значит и не надо, "Построишь выборку" на чём-нибудь другом, чего в аксессе нету.
А в Delphi, если всё-таки надо - можешь свой combobox создать - какой хочешь.
Про сервер:
всё Павел сказал...
18 янв 01, 16:25    [32036]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
BAlex
Guest
Попробуй ПРОЕКТ Access 2000. Клиент - тот же самый Access, и комбобоксы те же. БОльшую часть функций лучше вынести на SQL Server. И главное, учить мат. часть.
19 янв 01, 19:18    [32037]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
maximF
Member

Откуда: Kiev
Сообщений: 62
2 AlexeiAN:

Насчёт интерфейса:
- в VFP - есть многоколоночные combobox. Хотя такую вещь как фокс сегодня и врагу не пожелаешь
- для дельфей можно найти любой контрол, благо библиотек море.
- да и вообще какую особую функциональность добавляет к обычному списку многоколоночный? Конкатенируй себе строки - вот и вся многоколоночность.

Хотя самое сложное, конечно, после такой програмулины как эксесс перейти на неигрушечную СУБД.
20 янв 01, 15:47    [32038]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Павел
Guest
Для тех, кто есче не понял: проект Access 2000 это не СУБД, а клиент с интегрированными средствами разработки баз MSSQL Server 6.5 - 7.0. Собственно этот самый MSSQL (или MSDE - его порезанная весия) и является СУБД. А клиент бывает тонким, толстым, но про игрушечный впервые слышу.
22 янв 01, 06:17    [32039]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
alvako
Guest
To: Павел
>А клиент бывает тонким, толстым, но про игрушечный впервые слышу.
А кто то говорил про игрушечного клиента? Про неигрушечную СУБД - говорили...но не про клиента.
24 янв 01, 08:02    [32040]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Павел
Guest
Согласен.
25 янв 01, 05:38    [32041]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Serge
Guest
Гм. ODBC - технология медленная и устаревшая?!
29 янв 01, 20:02    [32042]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Павел
Guest
Именно. Медленная из-за своей универсальности ('открытости'). Устаревшая из=за того, что есть OLE DB. Хотя честно говоря самый быстрый способ общения с сераером - через его собственный (native) API.
30 янв 01, 15:44    [32043]     Ответить | Цитировать Сообщить модератору
 Кто тут Delphi обижает?  [new]
Oleg F
Guest
Кто тут говорит, что у Delphi нет многоколоночного combobox?
Есть, называется он DBComboBox. Правда, он берёт колонки только из таблицы базы данных, просто так, без таблицы, данные ему не подсунуть. Но, как я прочитал, разработчику на Acess, который затеял эту дискуссию, именно это и нужно.
30 янв 01, 17:12    [32044]     Ответить | Цитировать Сообщить модератору
 ODBC  [new]
Serge
Guest
Честно говоря, не понимаю, каким образом OLEDB может быть
быстрее ODBC. Всякие навороты с передачей данных через
VARIANT вряд ли будут быстрее, чем обмен через буфера ODBC.
Насчет native-библиотек - это, конечно, cool, но какой процент
времени займет сама прослойка ODBC-вызовов? По сравнению с
коммуникационными расходами - очень малый.
30 янв 01, 17:29    [32045]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Павел
Guest
Если дергать на С ODBC API то можно получить очень шуструю приладу. Но процесс разработки такой системы сложен и долог и сравним по сложности с работой напрямую с native API. А насчет скорости - попробуй поработать с данными посредсвом любого средства разработки, потдерживающего оба стандарта (Delphi>=5.1 или A2K). Вопрос снимется сам собой. И причем тут прослойка ODBC драверов? И ODBC и OleDB (исключая провайдера для ODBC источников - он оставлен только для перспективы перехода с ODBC на OleDb источник) являются 'обертками' вокруг native библиотек и никак между собой не взаимодействуют. Давным давно Borland'овцы придумалb SQLLink в пику ODBC, а теперь использует и OleDB. Или это не показатель?
31 янв 01, 06:23    [32046]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
f_w_p
Guest
По скорости : ODBC < BDE < ADO < API. Это аксиома. Симтоматично не то, что Borland вставил ADO в свои продукты, а то что MS отказалась от своего ODBC в пользу ADO. Использование API не означает обязательного усложнения проекта. Пример библиотека IBX для InterBase. Наверняка есть что-то подобное и для MSSQL. А вот что Access быстрее чем MSSQL для меня было откровением. Ничего более тормознутого чем Access я еще не встречал. Да и глючного то же.
31 янв 01, 13:00    [32047]     Ответить | Цитировать Сообщить модератору
 ODBC again  [new]
Serge
Guest
Реально на ODBC с поддержкой курсоров и
bulk operations можно написать приложение
настолько скоростное, что никакому OLEDB и не снилось.
В ODBC при исполнении подготовленных запросов вообще
никакой пересылки параметров не происходит. Данные
вытаскиватся прямо из буферов приложения.

Сложность разработки объясняется именно возможно
оптимизировать, причем независимо от СУБД.
Причем потери скорости по сравнению с native api
минимальные, об этом я уже писал.

Товарищи из Microsoft забыли, похоже, что есть такой
язык C, и оставили нам только запутанный набор
интерфейсов под названием OLEDB. Нигде в MSDN не помню
утверждения о том, что OLEDB быстрее. Несут только всякую
чушь про "универсальный доступ к данным"...
1 фев 01, 19:33    [32048]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Павел
Guest
Похоже что наша дискуссия теряет смысл. В Books Online указывается, что и ODBC и OleDb драйвера для MSSQL native. Логично предположить, что вызовы аналогичных функций происходят со сравнимой скоростью. НО! Мне, например, никуда эти вызовы не упираются. Мне MSSQL нужен для создания, ведения и сопровождения корпоративной базы. И нет у меня времени, чтобы играть с ODBC или OLEDB API. Сами бизнесс-процессы, логика приложения отнимает такую кучу времени и сил, что мне по сути до лампочки насколько у меня оптимизированы низкоуровневые вызовы. И опять НО! Встает закономерный вопрос: а как быстро разрабатывать клиентскую приладу, не вникая в дебри (если во все вникать, то и С не нужен, теоретически можно писать все на азме или прямо в кодах) и не получить на выходе слабоработоспособную и тормозную поделку?. И тут мелгомягкие и разродились на ADO. ADO базируется на OleDb, предоставляя с одной стороны скоростной доступ к серверу, а с другой - достаточно простые и функциональные средства для разработчика. Для ОDBC аналогичной по скорострельности и функциональности 'обертки' мне неизвестно.
2 фев 01, 05:47    [32049]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
AlexeiAN
Guest
Не ожидал, что дискуссия уйдёт в сторону ODBC. Занялся изучением матчасти, но число вопросов-проблем только возросло.
Скорость работы SQL-server-7.0 проверял НЕ по сети, НЕ через ODBC, а напрямую открывал таблицу в SQl-server; здесь скорость выборки была раза в 3 ниже Access2.
Попробовал конвертнуть программу из Access2 в Access2000 и подключить к SQl-server; скорость выборки данных оказалась ниже раз в 15-20, т.е. то, что Access2 делает за 2-3 сек. Access2000+SQL-server делает за 30-60 сек.
Вообще под многоколоночным combobox я понимаю, например, вот что: выбор товара из списка, для которого по-колоночно выдается: артикул, название, цена в рублях, цена в долларах, количество на складе. Перед этим списком оператор выбрал категорию и подкатегорию товара, чтобы сократить список товара. Мне для программы надо знать код товара и код под/категории (оператору - не надо их видеть, т.е. они является скрытыми колонками в combobox товара). К тому же есть колонка "нет товара", т.е. товар с этим признаком показывается, если нажата спец.кнопка в форме. Да еще для каждой колонки нужен разный формат: деньги, дата, 0.###, ""/НЕТ и т.д. Такого рода combobox я использую везде, т.к. он занимает на экране лишь одну строку, а списков в одной форме может быть 3-10.
Удалось найти способ создания многоколоночных combobox в Delphi, но пока не нашел способ получать значения из колонок. Перерыл много библиотек с компонентами; в RXlib, например, как величайшее достижение есть выборка из combobox по первым буквам (в Access2 это само собой разумеющееся и все мои операторы этим очень пользуются). Кстати, оформление полей в Delphi сделано очень неудобно, надо выбирать значение, да ещё найти, где, т.е. щелкать мышью приходится раз 10, бегая по всем properties. В Acces2 это сделано через pallete и сводится к паре щелчков мыши. Да ещё есть откат. Такого рода вещи я и назвал элементарными, но их нет в других средствах, поэтому они и кажутся примитивными с точки зрения удобства разработки программы.
Читаю книгу по SQL-server-7.0 (1999 года издания) и чем дальше, тем хуже. Например, написано, что для проведения каскадных изменений в связанных таблицах надо писать триггеры (вообще-то Access2 делает это сам). Хранимые процедуры надо каждый раз перекомпилировать (добавлять with compile), если в таблице удалены, добавлены или изменены данные (пардон, но это и есть работа в БД!). Ну и так далее. Но больше всего позабавила целая глава, посвящённая созданию резервных копий БД хитрыми способами, т.к. "БД может разрушаться и сохраняться надо ежедневно, а то и ежечасно". Приехали. Это называется надежность класса C2. В Access2 у меня нет таких проблем. Особенно сейчас, когда сменил сетевые карты.
13 фев 01, 19:53    [32050]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
vitaly
Guest
Привет
Как насчет статистики - а то очень интересно
если возможно - выборка из таблиц 100 000 и 100 000 000 записей очень интересно
а то я не разу не слышал что access быстрей
Спасибо за ответ
Кстати какой размер базы - у меня к примеру 1.5 Gb

Насчет IDE о вкусах не спорят но я думаю ты к нему привык
14 фев 01, 01:38    [32051]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Павел
Guest
2 AlexeiAN:

>Скорость работы SQL-server-7.0 проверял НЕ по сети, НЕ через ODBC

Сильно. А я, как и команда разработчиков MS SQL наивно пологал, что существует понятие клиентской и серверной net-library, в том числе и Shared memory, через которые осуществляется АБСОЛЮТНО ЛЮБОЕ взаимодействия клиента и сервера. Доступ к клиентской net-library можно получить ТЛЬКО ТРЕМЯ СПОСОБАМИ: используя DB-library, ODBC или OleDB провайдер. Но Вы умудрились обойтись без этого. Поздравляю.

>а напрямую открывал таблицу в SQl-server

Т.Е. клиенту данные не отсылались... А как Вы скорость то мерили тогда? Ну удалось, так удалось. Снова поздравляю.

>Попробовал конвертнуть программу из Access2 в Access2000 и подключить к SQl-server; скорость выборки данных оказалась ниже раз в 15-20, т.е. то, что Access2 делает за 2-3 сек. Access2000+SQL-server делает за 30-60 сек.

Дело в том, что обработку данных по прежнему осуществляет Jet, а сервер их только хранит. Но даже при таком подходе можно добться многократного повышения бысродействия, надежности хранения и защиты данных. Просто SQL сервер штука не простая, его надо уметь правильно настроить для получения действительно выдающихся результатов.

>Читаю книгу по SQL-server-7.0 (1999 года издания) и чем дальше, тем хуже. Например, написано, что для проведения каскадных изменений в связанных таблицах надо писать триггеры (вообще-то Access2 делает это сам)

Купите книгу по MsSQL2K 2001 года издания.

>Хранимые процедуры надо каждый раз перекомпилировать (добавлять with compile), если в таблице удалены, добавлены или изменены данные (пардон, но это и есть работа в БД!).

Выкиньте эту книгу. Если конечно там прямо так и написано. Хотя я сомневаюсь.

>Но больше всего позабавила целая глава, посвящённая созданию резервных копий БД хитрыми способами, т.к. "БД может разрушаться и сохраняться надо ежедневно, а то и ежечасно".

Нет, Вам вовсе не недо делать это ежедневно или ежечасно. Можно вообще не Backup'ить. Только при грамотном построении плана резервного копирования (заметьте, полностью автоматизированого!) можно очень быстро откатываться к данным, измененным хоть месяц, хоть час назад (а при желании и 5 мин. назад)

>В Access2 у меня нет таких проблем. Особенно сейчас, когда сменил сетевые карты.

Не надо быть провидцем, чтобы с уверенностью сказать - если вы пытаетесь создать серьезную систему - БУДУТ. По крайней мере никто из мне известных разработчиков на Ассеss без проблем в этом отношении не живет. Ну а если Ваши проблемы заключались в используемых сетевушках, не расслабляйтесь! Еще есть память, процессор, жесткий диск, материнская плата, тупой пользователь и Господь Бох.


2 vitaly:

>Кстати какой размер базы - у меня к примеру 1.5 Gb

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

>Насчет IDE о вкусах не спорят но я думаю ты к нему привык

Абсолютно с Вами согласен!
14 фев 01, 07:57    [32052]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
qu-qu
Guest
Кстати, я 4 года "работал" с корпоративной системой, в которой хранилищем (и "обрабатывалищем") данных был MS SQL (последовательно сменились 3 версии), а "клиентская часть" была написана на Access 2.0 и запускалась "рантаймом" на компутерах пользователей, коих было в сети больше 50-ти, и одновременно работали с системой около 30-ти... Никакого OLEDB 2-рой Access не знал, и работало все исключительно через ODBC (причем старый 16-ти разрядный), и работало довольно "шустро" как в интерфейсной части, так и на сервере.

Просто должен соблюдаться Главный Принцип таких клиент-серверных "связок" - никаких лишних данных не гонять по сети от сервера к клиенту, все что может быть обработано на сервере - ДОЛЖНО обрабатываться там. Естественно, если "всаживать" в комбо-бокс "список товаров" на 40 000 наименований (а именно с такими объемами приходилось работать), то будь он (комбо-бокс) хоть в 100 раз более замечательный чем в Дэльфи - это будет не "быстрая и удобная работа интерфейса", а хрен знамо что...

Хотя, как раз именно про "интерфесные способности" Access-а для работы с данными я совершенно согласен с автором ветки - я НЕ ВИДЕЛ ИНТЕРФЕЙСА ЛУЧШЕ И УДОБНЕЕ Access-а (пришлось пробовать и VB, и VFP, и C).
15 фев 01, 11:06    [32053]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Павел
Guest
2 AlexeiAN:
Неожиданно дшло: А Вы пробовали проекты ADP Acctss2K? Если нет, то обязательно посмотрите! Презабавная вещь! Вот тут А2K + MsSql действительно отрывается!
17 фев 01, 21:47    [32054]     Ответить | Цитировать Сообщить модератору
 О как я тебя понимаю.......  [new]
Moth
Guest
Я сам пишу на MSSQl 7.0 + Access 97

Болею преходом на MS VC

Про вопросы.
Как уже правильно сказали все селекты надо делать на сервере. Скарости возростают. Правда есть некоторые тонкости:
1. Индексы. Особенно кластерные.
2. Написание запросов через INNER JOIN
3. Железки серыера и объем ОЗУ. Из истории: Процедура по закачиванию информации построчно PIII 400 RAM HDD 20 IBM 5400. Ну так надо было. 4 часа. Ставлю рейд конроллер - 60$ и результат - 1 час. Рейд просто как переходник. Без зеркалов ип прочих примочек.
4. Acceess 2.0 не сковсем корректно работает с датами более 2000 года. Пришлось брать 97.
5. Сам Access еще та штучка. Очень любит блокировки. Берешь Форму в которую возвращаются 5000 записей и смотришь как на сервере лочатся таблицы. Это обходимы штуки. Если интересно напишу на мыло.
6. Берем комбо бокс из 2000 записей. и та же песня с блокировками. Тоже обходится в параметрах запроса пишишь (NoLock) И все работает.
7. Access 97 очень любит увеличиваться в объемах. Делаешь сжать и файл уменьшается раз в n.

Про отчеты.
1. Очень я люблю за это Access. Просто. В других языках с этим сложнее. Правда в VB есть quickreport а в Delphi CristalReport или наоборот.
2. Есть допольнительные ActiveX компоненты под VB с готовыми бланками отчетов.
3. В Delphi можно в списке уакзать несколько столбцов и будет так как ты привык видеть в Accesse. У Microsoft с этим проблемнее, но решаемо.
4. На C делаешь все сам ручками. НО если тебя страшит написать цикл и если нужна группировка, то и вложенный тут уж изинятес.

Итого.
Если тебе надо через каждые 5 минут разворачивать проект перпендикулярно, то Access само то. По скорости можно залечить более крутыми процами. Если необходимо открывать 2-4 Accessa и с каждым работать, то лучше брать PII, PIII или Aslonы. Celeron & Duron не справится.

Если ты готов потратить время на написание именно "системных" вещей и ТЗ более менее устоялось и закостенело, то бери C Bilder или MS. Ниже есть конференция можешь спросить, что не так.


moth.
moth@mail.primorye.ru



Moth.
moth@mail.primorye.ru
19 фев 01, 11:14    [32055]     Ответить | Цитировать Сообщить модератору
 RE:Помогите выбрать БД и средство разработки  [new]
Сергей Орлов
Guest
В принципе без разницы, что использовать, VB, VFP, Access(2,97,2000), ODBC, OLEDB. Главное в правильном переходе на технологию клиент-сервер, т.е. клиент должен запрашивать только те данные, которые он может отобразить. Пример на форме видны только 10 записей, вот клиенти должен их запрасить у сервера, в противном случае запрашивается миллион записей, затем на них клиент накладывает фильтр, чтобы отобразить 10 видимых, этож какую сетку и какой компьютер, на котором работает клиент, надо иметь
29 июн 01, 05:35    [32056]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Помогите выбрать БД и средство разработки  [new]
PROSHEV S.
Guest
Абсолютно согласен! Что только не пробывал, НО, ACCESS самый реальный.
29 июл 03, 15:30    [280005]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать БД и средство разработки  [new]
NOV
Guest
Проблема автора не в средстве разработки, а в том, что он до сих под думает
по Accessному, наверняка крутит свои процедуры написаные в Access, а сервер использует как хранилище данных.
У меня был такой кадр, FoxProшник правда но беда у вас одна, он брал
таблицу закручивал по ней цикл и менял значения определенных полей, а потом возмущался, что в фоксе эта процедура выполнялась не больше минуты, а с SQL сервером 8 минут, и тоже кричал тормоз тормоз, когда я написал обыкновенный udate по выборке, эта процедура стала делаться за секунды, он заткнулся и сел за книги.
Забудь про свои процедуры, учи SQL, когда бошку развернешь, со скоростью все нормально станет.
А через, что работать по большому счету всеравно, конечно небольшая разница в производительности будет, но если база спроектированна, нормально, и ты нормально используешь клиент-серверные технологии то, способ доступа без разницы.
30 июл 03, 14:32    [281671]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить