| Oleg_k |
| Отправлено: 31.08.2004, 19:40 |
|
Не зарегистрирован
|
Народ, помогите разобраться! Как организовать поиск в БД используя метод Seek компонента ADOTable (база Access)! В исходной таблице есть составной индекс из 4 столбцов. Что это за тип такой -Variant?
Заранее благодарен! |
|
| olegenty |
| Отправлено: 01.09.2004, 08:02 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
1. не задавай в форуме пахабных вопросов типа
| QUOTE |
Что это за тип такой -Variant?
|
поскольку его описание есть
1.1. в Help
1.2. в сорцах
хоть обчитайся
2. а верна ли постановка задачи??? почему не TADOQuery c уточнением, а именно Seek по (о ужас!!!  ) TADOTable? ты точно уверен, что на таблице в несколько сотен тысяч Seek — верное решение???
да, ну а если всё так, то ораганизуй поиск, как написано в справке. там всё приподробненько описано. английским по цвету clWindow 
|
|
| Guest |
| Отправлено: 01.09.2004, 19:34 |
|
Не зарегистрирован
|
| QUOTE (olegenty @ 01/09/2004, 09:04) | ты точно уверен, что на таблице в несколько сотен тысяч Seek — верное решение???
|
Нет не уверен! Если бы был уверен вопросы бы не задавал! Подскажи, пожалуйста, как правильно организовать поиск по ключевому полю в базе Access97!
А с типом Variant справка мне не очень помогла — толи мой Eng хромает толи опыта еще мало в програмировании, потому и обратился за помощью!
Буду благодарен за любой совет! |
|
| Guest |
| Отправлено: 01.09.2004, 19:39 |
|
Не зарегистрирован
|
| QUOTE (olegenty @ 01/09/2004, 09:04) | ты точно уверен, что на таблице в несколько сотен тысяч Seek — верное решение???
|
Нет не уверен! Если бы был уверен вопросы бы не задавал! Подскажи, пожалуйста, как правильно организовать поиск по ключевому полю в базе Access97!
А с типом Variant справка мне не очень помогла — толи мой Eng хромает толи опыта еще мало в програмировании, потому и обратился за помощью!
Буду благодарен за любой совет!
P.S. А в справке так и написано английским по clWindow — используйте Seek для поиска в поле содержащем индекс! |
|
| AVC |
| Отправлено: 02.09.2004, 08:14 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE |
| QUOTE | (olegenty @ 01/09/2004, 09:04)
ты точно уверен, что на таблице в несколько сотен тысяч Seek — верное решение??? |
Нет не уверен! Если бы был уверен вопросы бы не задавал!
|
olegenty вам прозрачно намекает, что при работе с SQLелевскими базами хорошей практикой является использование не таблиц а запросов и ограничение объема выборки желательно делать еще в момент выполнения запроса. Если вам нужна только одна запись и не в сетке, то лучше выбрать именно ее чем использовать Seek по огромной таблице. Кроме того в SQLелевских базах понятие "ключевое поле" для поиска абсолютно не критично. Сервер делает выборку всегда, только иногда быстрее, а, иногда, медленнее.
Variant, грубо говоря, это тип, способный правильно хранить и преобразовывать значения большинства других базовых типов данных. В первом приближении напоминает union (как это и было в ранних реализациях) теперь com класс. Список методов можно получить в Help'е. |
|
| Guest |
| Отправлено: 02.09.2004, 20:15 |
|
Не зарегистрирован
|
На счет запроса я с Вами полностью согласен — если мы хотим найти (отобрать) n -ое количество записей, которые отвечают некоторому условию(- ям)! Но нам нужна всеголишь 1 запись, которую нам нужно найти ! И я думаю, что запрос сдесь ничем не выигрывает перед Seek, темболее Seek — ето метод, специально предназначенный для поиска по ИНДЕКСУ, т.е. просмотра всей таблицы не будет!!! Поправте меня если я не прав!
На счет типа VARIANT — теоретически я понимаю что представляет собой этот тип (справку я читаю как это ни странно), но практически при его использовании в методе SeeK поиска не происходит. Поетому я предполагаю, что я не совсем понимаю как его правильно использовать!
Если можно помогите КОНКРЕТНЫМ ПРИМЕРОМ! |
|
| AVC |
| Отправлено: 03.09.2004, 08:28 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE | И я думаю, что запрос сдесь ничем не выигрывает перед Seek, темболее Seek — ето метод, специально предназначенный для поиска по ИНДЕКСУ, т.е. просмотра всей таблицы не будет!!! Поправте меня если я не прав!
|
Так и есть для СУБД типа dbase где ваше приложение прикидывается сервером и управляет базой на физическом уровне.
Но вы абсолютно не правы если работаете с SQLевской базой. При выполнении запроса формируется (открывается) так называемый курсор, который можно рассматривать как временную таблицу. Физическое управление этим курсором лежит на сервере. При Seek'е (Locate) данные обязательно извлекаются из курсора для сравнения. Т.е. если мощность выборки составляет 200 000 записей и мы хотим найти последнюю то придется извлечь 199 999 не нужных записей. Поэтому запрос вида
Select * From ttt Where key_field = key_value
для получения одной записи несомненно выгоднее.
Кстати, я уже упоминал, что наличие/отсутствие ключевых полей или индексов ни как не сказывается на возможности выполнения запроса, а только на скорости выполнения.
По вариантам пример:
QryMain->Locate(FQryMain_PKName, oldcode, TLocateOptions());
позиционирует DataSet по ключевому полю на нужную запись |
|
| Guest |
| Отправлено: 03.09.2004, 16:11 |
|
Не зарегистрирован
|
Обясните мне, прожалуйста, зачем тогда разработчие включил в ADO такой "непроизводительный" метод Seek. НЕ в одном источнике, которыми я пользовался, не говорилось — используйте запрос для более эфективного поиска. А четко сказано используйте — SEEK! Или вы хотите сказать он создан для неопытных програмистов, типа Меня , чтобы не усложнять им жизнь!
Если Вы можете, то дайте пожалуйста, пару сылок, где я могу в целях повышения образованости, узнать о способах организации БД и методах повышения эффективности работы с ними!  |
|
| AVC |
| Отправлено: 03.09.2004, 17:17 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE | | Обясните мне, прожалуйста, зачем тогда разработчие включил в ADO такой "непроизводительный" метод Seek. |
ADO может поддерживать связь с разнообразными источниками данных, в том числе и с теми где метод Seek будет оправдан. Мы же речь ведем о SQL'евских базах в которых ответственность за физическое расположение данных и способах доступа к ним лежит на сервере. Т.е. если вы даже используете компонент таблица на самом деле вы неявно работаете с запросом вида Selec * From Table так как сервер ни кому не позволит работать напрямую с физической таблицей. Поэтому для поиска выгоднее использовать запрос.
Из примечания в моем Help'е следует что метод Seek "is only supported for use with Microsoft Access2000 and the Jet 4 provider" с кучей дополнительных ограничений. Я же пытался вам рассказать про "общий случай" поиска записей в SQL'евских базах.
| QUOTE | ... узнать о способах организации БД и методах повышения эффективности работы с ними!
|
Зависит от используемой СУБД. Например Том Кайт "Oracle для профессионалов"
Несколько общих советов (в SQL'евских базах)
Везде где можно использовать Select.
Select работает быстрее цикла.
Лучше использовать Select чем функцию.
В Selecte ограничивать объем выборки как можно раньше.
Лучше обходиться без Having |
|
| Guest |
| Отправлено: 03.09.2004, 17:32 |
|
Не зарегистрирован
|
Спасибо за совет! Попробую запросы!
А до оракла мне еще далико — тут бы с access ' ом разобраться!
А Вы работаете с ораклом, как я понял их контекста?
В каких слкчаях он предпочтительней Access на Ваш взгляд?
А Вы не можете посоветоваь ссылки в инет на инфу о
работе с БД? А то с книгами прблемы — вечно нет тех что надо! |
|
| AVC |
| Отправлено: 06.09.2004, 09:39 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE | | А до оракла мне еще далико — тут бы с access ' ом разобраться! |
Если вы знаете принципы SQL то работать можно практически с любым сервером (не путайте с администрированием). Простые запросы выполняются везде. Для остальных достаточно уточнить синтаксис и ограничения.
| QUOTE |
А Вы работаете с ораклом, как я понял их контекста
В каких слкчаях он предпочтительней Access на Ваш взгляд?
|
И с ним в том числе. СУБД выбирается в первую очередь в зависимости от поставленной задачи и финансовых возможностей заказчика если требуется лицензирование. Для себя я делю СУБД на 3 класса
1. Большие (Oracle, MSSql, Sybase ...) для случая, когда много таблиц сложной организации с большим объемом информации, а время ответа должно быть не большим.
2. Средние (ASA, MaxDB, Interbase ...) для решения задач небольшиго предприятия (одновременная работа до 10-ти станций).
3. Карманные (не SQLевские) (dbase, Paradox ...) для хранения данных локального приложения или для обмена данными между приложениями, работающими с классами 1 и 2.
Access я не включил в список намеренно. Считаю, что его место на грани 3 — 2 и, кроме того, у него есть собственные средства разработки приложения.
(Но все это мое личное мнение)
| QUOTE |
А Вы не можете посоветоваь ссылки в инет на инфу о
работе с БД? А то с книгами прблемы — вечно нет тех что надо!
|
Нет. Предпочитаю "живые" книги. Поищете, например, на Google — такой информации должно быть море. |
|
| Guest |
| Отправлено: 06.09.2004, 18:50 |
|
Не зарегистрирован
|
Я в Вашем списке не увидел Акцес, или он скрывается под ASA?
И еще, один вопрос, если можно: как вставлять новые записи — тоже c помощю запросов или всетаки можно использовать банальный Insert!
Большое спасибо!
|
|
| AVC |
| Отправлено: 07.09.2004, 08:20 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE | | Я в Вашем списке не увидел Акцес |
Поищите по слову Access (подсказка: после пункта 3)
| QUOTE | как вставлять новые записи — тоже c помощю запросов или всетаки можно использовать банальный Insert!
|
Смотрите мой пост от 03/09/2004, 17:19 — Везде где можно использовать Select.
Можно все что разрешено. Вопрос эффективности решается для каждой конкретной СУБД отдельно. На SQL'евских базах "банальный Insert" (метод TTable — я правильно понял?) транслируется в банальный запрос Insert into. Выводы делайте сами .
Судя по вашим вопросам вы привыкли работать с СУБД класса dbase/paradox где оперируемой единицей информации является запись (строка, кортеж ...). В SQL оперируемой единицей является таблица (выборка, курсор, запрос ...) (не путать с таблицей хранения данных) и все операции SQL надо рассматривать в этом аспекте. Т.е., по поводу Insert, конструкция Insert into table Select * from other_table вставляет сразу много строк из other_table в table и выполняется сервером, который может использовать свои возможности наиболее эффективно. |
|
| Guest |
| Отправлено: 07.09.2004, 22:03 |
|
Не зарегистрирован
|
Данкишон!
Как я не заметил про Аccess не знаю! После работы внимание на нуле!
Я, наверно Вас достал, но всетаки, не сочтите за труд: если запрос вернул n запесей, которые не были ни как не упорядочены, они будут расположены в порядке их добавления в базу или как бог даст?
(База Ассess) |
|
| AVC |
| Отправлено: 08.09.2004, 08:06 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE | если запрос вернул n запесей, которые не были ни как не упорядочены, они будут расположены в порядке их добавления в базу или как бог даст?
|
Как бог даст. Если это не так, то вам на этот раз просто повезло. В SQL принято, что при отсутствии Order by порядок произвольный. |
|
| Guest |
| Отправлено: 08.09.2004, 23:35 |
|
Не зарегистрирован
|
Есть несколько реплик 1 базы (акцес)! Почему я не могу получить доступ к репли ке через ADO! Выдает ошибку! Хотя когда база не является репликой все работает отлично! Спасибо! |
|
| Nick |
| Отправлено: 09.09.2004, 08:45 |
|
Машинист паровоза
Группа: Участник
Сообщений: 247
|
С базами Access лучше работать его же средствами.
В последствии даже .exe сделать.
Если хочешь писать в BCB выбери другую базу.
1. Для простенькой локальной задачи DBase, Paradox, IBase (FireBird) на крайняк.
2. Для небольшой сетевой IBase (FireBird).
3. Для крупной задачи Oracul, MS SQL.
Это конечно мое мнение.
Работал с Paradox в DOS (проблемы при сбое питания),
работал в Win с Access (в сети более 5 комп тормоза).
Счас работаю FireBird — очень большая разница.
|
|
| AVC |
| Отправлено: 09.09.2004, 08:45 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
И Access и ADO детище Microsoft — вопрос к ним. |
|
| AVC |
| Отправлено: 09.09.2004, 08:55 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
2 Nick абсолютно с вами согласен (см. мой пост от 06/09/2004, 09:41)
(а если вы поработете еще например с MaxDB или ASA разница станет еще более ощутимой)
Guest — если еще не поздно замените Access на любой сервер из группы 2. Если вас смущает финансовый вопрос — они либо бесплатные, либо не очень дорогие.
Отредактировано AVC — 09/09/2004, 08:59 |
|
| Guest |
| Отправлено: 09.09.2004, 21:03 |
|
Не зарегистрирован
|
А они поддержуют репликацию? |
|
| Nick |
| Отправлено: 10.09.2004, 08:02 |
|
Машинист паровоза
Группа: Участник
Сообщений: 247
|
2 AVC
MaxDB или ASA
что в них вкусненького
переходя с Access на FireBird
я восторгался триггерами и хранимыми процедурами
и UDF немного
и транзакциями конечно, хотя в Access они тоже есть,
но об этом я узнал только когда уже делал проект в BCB |
|
| AVC |
| Отправлено: 10.09.2004, 09:09 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Guest — ASA — да. Остальные — не интересовался.
Nik
Наличие триггеров, SP, conctraint'ов и транзакций даже не оговаривается. Это просто обязано быть.
Например ASA очень последовательно подходит выборкам: результат любой выборки это виртуальная таблица с которй можно делать на следующем уровне все, что разрешено для таблиц. И так до бесконечности. Например update на ASA можно написать такой, который даже Oracl'у не снился.
Или еще маленькие удобства — в сессии можно объявлять хранимые на сервере переменные (в стиле Clipper private) на время жизни сессии и использовать их в запросах. Переменная может быть таблицей, с которой можно работать как с обычной таблицей. Это в совокупности с допустимостью множества SQL команд в одном запросе позволяет организовать "конвейерное" выполнение запросов.
Да, конечно, всего этого можно добиться при помощи View и SP. Но, согласитесь, приятнее когда это просто текст без дополнительных телодвижений типа Create и Drop.
У IB (не знаю как у FB) был один очень существенный недостаток (может, конечно, я не до конца разобрался с назначением прав). Права доступа применялись не для базы данных а для сервера. Т.е. берешь закрытую базу (физ.файлы) цепляешь её не другой сервер — и, опаньки, видишь всю информацию. При разработке коммерческого приложения очень сложно объяснить клиенту почему конкуренты (или налоговая) могут очень легко увидеть их данные. Сервера, которые я привел в примерах защищают именно базу. Пока не введешь правильную парочку пользователь/пароль тебе ни кто не поможет.
|
|
| Nick |
| Отправлено: 11.09.2004, 08:28 |
|
Машинист паровоза
Группа: Участник
Сообщений: 247
|
2 Guest
в FireBird нет репликации,
сделал лерез лог таблицу которая заполняется
тригерами на изменение, тем более что в филиалах не нужна полная информация, а только документы относ к этому филиалу а справочники полность реплицируются.
2 AVC
Да именнованных констант не хватает
другие вещи можно сделать View и SP.
в версии FB 2 обещали исправить защиту.
мне тоже это не нравится.
ASA — чья разработка и какие драйвера и компоненты нужны ?
|
|
| AVC |
| Отправлено: 13.09.2004, 09:20 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE |
ASA — чья разработка и какие драйвера и компоненты нужны ?
|
ASA это Adaptive Server Anywhere. Разработка Sybase. Имеет большинство возможностей "большого" Sybase. Ставится на все, начиная с Win3x. Драйвера ставит сам. Доступ через ODBC (ADO/BDE) (может уже есть "прямые" компоненты).
| QUOTE |
другие вещи можно сделать View и SP.
|
Недавно здесь же была полемика на эту тему. Я остался при своем мнении и позволю повториться:
... всего этого можно добиться при помощи View и SP. Но, согласитесь, приятнее когда это просто текст без дополнительных телодвижений типа Create и Drop.
Кроме того этот текст можно хранить как поле некой служебной таблицы и вносить изменения только в него (не требуется перекомпиляция, линковка и распространение обновленных версий, создание view и sp, расстановка прав ...) |
|
| Guest |
| Отправлено: 13.09.2004, 23:26 |
|
Не зарегистрирован
|
Что такое тригеры? И для чего они применяются! |
|
| AVC |
| Отправлено: 14.09.2004, 08:41 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Уважаемый гость, достаньте и прочтите учебник по SQL с примерами реализации на каком либо сервере. Не хочется излагать здесь учебный курс.
Триггер — это SP запускаемая при наступлении определенного события. Применяются для выполнения нужных действий при наступлении данного события (например тонкая проверка целостности БД или каскадное обновление). |
|
| olegenty |
| Отправлено: 20.09.2004, 10:49 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
Приношу извинения за неответ — был в отпуске. Присоединяюсь к тому, что сказали AVC и Nick. Особенно по поводу того, что для начала тебе невредно просто отвернуться от компа и почитать литературы по
1. стандарту синтаксиса SQL
2. нескольких серверах БД в целом
3. расширения синтаксисов SQL на серверах
затем определиться с решаемой задачей, и выбрать конкретную СУБД. не Access, потому что рано или поздно твой уровень дорастёт до того, что ты осознаешь и будешь вынужден перенести свой проект на другой сервер SQL (если это не телефонный справочник и предполагает работу в сети)
основной недостаток Access — отсутствие хранимых процедур и триггеров, которые и делают львиную долю всей работы (в противном случае уйма правил работы с данными (или бизнес-правил, или бизнес-логики, называй, как удобней) лягут на сторону клиента. например, при вставке записи в одну таблицу модифицируются данные других таблиц. в случае SQL базы, это реализуется в триггере, и всю работу делает сервер. в случае Access, ты будешь вынужден все управляющие модификацией данных других таблиц запросы делать из своего клиентского приложения. если сделать это грамотно, то лишних фетчей-то можно избежать, но любая модификация правил работы с данными ВСЕГДА повлечет изменение модифицирующего скрипта и перекомпиляцию исходника — это минимум, если ты скрипты модификации параметрически куда-то грамотно вынесешь (в свой компонент ли, или ещё куда-то), или ещё и дописывание/модификацию нового кода, если завяжешься на "тупое" процедурное событийное программирование).
|
|
| olegenty |
| Отправлено: 20.09.2004, 11:04 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
стоп, насчёт "ВСЕГДА ... перекомпиляцию ... " я погорячился, можно и без перекомпиляции обойтись, просто договориться с собой самим о правилах генерации скрипта. но это будет уйма дополнительной работы по изобретению велосипеда и привязка к жестким правилам, любой отход от которых приведёт к нарушению функциональности.
|
|
