Какую технологию для доступа к данным выбрать ?

← →
mefisto (2005-10-27 17:13) [0]

Здраствуйте!Какую технологию доступа к данным (IBServer 6.5) (клиент-серверое приложение) выбрать (ADO,dbExpress, BDE, InterBase Express) или что-то иное. Посоветуйте. Лично я приклоняюсь к ADO НО при пробном подключении у меня возникти трудности.
Заранее спасибо!!!

← →
Johnmen © (2005-10-27 17:16) [1]

FIBPlus
Лучшей библиотеки прямого доступа я не знаю.

← →
Amoeba © (2005-10-27 17:20) [2]

Для подключения к Interbase родной и самой эффективной во всех отношениях технологией являеются библиотеки компонентов прямого доступа - Interbase Express или, что еще лучше, FIBPlus. Все остальные таковыми не являются. В сторону ADO (это доступ через одно известное место) или BDE (это давно уже вчерашний день) смотреть не стоит.

← →
mefisto (2005-10-27 17:34) [3]

Ну мне вообще нравиться MSSQL SERVER, НО ЦЕНА его кусаеться может кто-то подскажет сылку на его безплатную версию (Personal Edition) Буду очень рад!!

← →
mefisto (2005-10-27 17:34) [4]

Удалено модератором

← →
Johnmen © (2005-10-27 17:45) [5]

Ты бы не дёргался туда-сюда...
Определился бы, что тебе надо.

← →
mefisto (2005-10-27 18:06) [6]

Johnmen © IBServer 6.5.!!!!!!! У меня на нем база зараждаеться. А ввобще какая круче всех (ну кроме конечно ORACLE)?

← →
Johnmen © (2005-10-27 18:08) [7]

Определение крутизны дай пожалуйста.

← →
mefisto (2005-10-27 18:13) [8]

Johnmen © скорость доступа и поиска (например при 100тис записей в табле), размер дистибутива, простота в использовании, сист. требования

← →
sniknik © (2005-10-27 18:15) [9]

> А ввобще какая круче всех (ну кроме конечно ORACLE)?
оно не самое крутое, оно "распиаренное" как самое крутое (чего не бывает). а если сравнивать по конкретным задачам, то маленький локальный движок будет "круче" т.к. более подходящ под задачу.

← →
Johnmen © (2005-10-27 18:18) [10]

>mefisto (27.10.05 18:13) [8]
>Johnmen © скорость доступа и поиска (например при 100тис записей в
>табле), размер дистибутива, простота в использовании, сист. требования

А какой критерий из этих самый крутой?
:)

← →
isasa © (2005-10-27 18:25) [11]

В сторону ADO (это доступ через одно известное место)

Легкомысленно ...
Учитывая поддержку ADO -> ADO.NET

← →
Desdechado © (2005-10-27 18:33) [12]

а что, IB6.5 бесплатен?
а крутизна - это понятие слишком зависимое от конкретной задачи
для 100 тыс строк можно и dbf использовать, быстро и задаром

← →
Fay © (2005-10-27 18:33) [13]

2 sniknik © (27.10.05 18:15) [9]
>> а если сравнивать по конкретным задачам, то маленький локальный
>> движок будет "круче" т.к. более подходящ под задачу.
Откуда такая уверенность? Напоминает "В браке оба супруга равны. Особенно жена". 8)

З.Ы.
Честно говоря, при малейшей возможности я выбрал бы какой-нибудь MSDE вместо "маленького локального" FB.

← →
Fay © (2005-10-27 18:36) [14]

Удалено модератором

← →
Desdechado © (2005-10-27 19:03) [15]

2 Fay
ты всегда используешь кувалду для забивания обойных гвоздиков?

PS
направление мыслей [13], [14] настораживает, особенно жена вприсядку

← →
Anatoly Podgoretsky © (2005-10-27 19:17) [16]

mefisto (27.10.05 18:13) [8]
Теория говорит, оптимизация может быть по только одному критерию, остальное ограничения данного критерия.
Так вот выдай критерий и укажи ограничения.

← →
Fay © (2005-10-27 19:22) [17]

2 Desdechado © (27.10.05 19:03) [15]
Сравнение не очень удачное, т.к. забивать гвоздики кувалдой не удобно.

← →
Zacho © (2005-10-27 20:50) [18]

2 mefisto :

Использовать IB 6.5 сейчас не имеет смысла - он сильно устаревший и отнюдь не бесплатный. Хочешь именно IB - купи последнюю версию (7.5 вроде бы ?). Хочешь бесплатный - возьми FB.

← →
sniknik © (2005-10-27 21:27) [19]

Fay © (27.10.05 18:33) [13]
> Честно говоря, при малейшей возможности я выбрал бы какой-нибудь MSDE вместо "маленького локального" FB.
что говорит о том что ты его просто лучше знаеш, он тебе более симпатичен, и т.д. или наоборот совсем не знаеш FB, а с MSDE хотябы сталкивался. а вовсе не изза "крутости" одного перед вторым.

p.s. это не спор. я сам бы MSDE выбрал. ;о), но если вдруг "припрет" (было уже такое) могу и в пользу FB "склонится".
(было это когда стыковались с одним офисом на IB, а у него нет ни DTS ни OpenRowset-ов, в общем ничего приличного для обмена. посудили, порядили да и решили... проще всего наши таблици прям у них в базе и держать... обмен выливается в простые запросы между таблицами. и ничего, нормально работает ;о), а вот как бы подошол под эту задачу "крутой" оракл? ;о))

← →
Fay © (2005-10-27 22:28) [20]

2 sniknik © (27.10.05 21:27) [19]
Странно что не упоминается вариант, где я знаю и то и другое. К тому же, в FB есть не так много мест, которые можно знать, не разбирая его на атомы. 8)

MSSQL [и MSDE - пророк его 8)] действительно мне более симпатичен, т.к.
1) я ему намного больше доверяю
2) мне (и не только) значительно удобнее с ним работать
3) он даёт больше возможностей (и ещё больше возможностей, которые используются пореже)

Не смотря на то, что в простоте установки с маленьким локальным FB ничто не сравнится, я сильно охладел к нему именно из-за его НЕнадёжности - с базой постоянно происходят неприятности, чего не почти наблюдается с "полным" сервером.
Я бы простил всё, но не это.

← →
sniknik © (2005-10-27 22:36) [21]

> где я знаю и то и другое.
это все в "и т.д." ;)

← →
Fay © (2005-10-27 22:40) [22]

2 sniknik © (27.10.05 22:36) [21]
Каюсь, как я мог не заметить 8))

← →
Zacho © (2005-10-27 23:29) [23]

Fay © (27.10.05 22:28) [20]
с базой постоянно происходят неприятности, чего не почти наблюдается с "полным" сервером

Странно.. Сам я, правда, для "локальных" задач использую Yaffil Personal (работает надёжно, никаких проблем не было), но не слышал о каких-либо проблемах в FB Emb. Может тебе стоит сделать воспроизводимые примеры каких-либо "неприятностей" с базой и послать баг-репорт разработчикам ?

> К тому же, в FB есть не так много мест, которые можно
> знать, не разбирая его на атомы. 8)

Просто любопытно, что именно ты имеешь в виду ? Я, на вскидку, могу предположить только два места, которые желательно знать на "уровне атомов" - сборка мусора и "планирование" запросов. Впрочем, для сравнительно небольших, "локальных" задач, это imho не существенно.

← →
sniknik © (2005-10-28 00:01) [24]

Zacho © (27.10.05 23:29) [23]
а вот подтянулись те кто лучше знает FB, и сипатизирует ему же... ;о)) как же продолжится игра дальше, на чьем поле будет перевес?

подождем тяжолую артилерию.... ;)

p.s. а мне вот оракл не нравится. глючный какойто.

← →
Zacho © (2005-10-28 00:12) [25]

sniknik © (28.10.05 0:01) [24]

Да дело не в том, что симпатизирую FB (действительно, я его знаю лучше), мне просто интересно было подробнее что именно имелось в виду в фразе "К тому же, в FB есть не так много мест, которые можно знать, не разбирая его на атомы".

А против MS SQL я ничего не имею, поскольку с ним почти не работал :)

P.S. А мне вообще нифига не нравится.. Особенно программы писать не нравится, глючные они какие-то получаются :-)

← →
Fay © (2005-10-28 00:18) [26]

2 Zacho © (27.10.05 23:29) [23]
>> Просто любопытно, что именно ты имеешь в виду?
Я хотел сказать, что если не зарываться "анатомию", то FB изучается очень быстро.

2 sniknik © (28.10.05 0:01) [24]
>> а мне вот оракл не нравится. глючный какойто
У меня к нему отношение похожее. Точнее уважительно-настороженное 8).
Только вот full scan в запросах вида
select * from TABLE1 where ID = 1 очень бесит.

← →
Zacho © (2005-10-28 00:21) [27]

Fay © (28.10.05 0:18) [26]
Я хотел сказать, что если не зарываться "анатомию", то FB изучается очень быстро.

Понятно. А я понял наоборот :)

← →
by © (2005-10-28 00:30) [28]

Fay © (28.10.05 0:18) [26]
Только вот full scan в запросах вида
select * from TABLE1 where ID = 1 очень бесит.
А индексы строит не пробовали? )

Очень трудно обсуждать, когда не знаешь обе базы на Вы

> А индексы строит не пробовали? )
я с ним не работаю, один раз тока ставил на пару недель потестить одну программу воможных партнеров. ну естественно не очень хорошо его не знаю. но на мои вопросы почему там у них и что, приехали два спеца по ораклу. и надо сказать они тоже не прояснили мне ситуацию (в итоге партнеры не состоялись ;).
а вопросы были простые (то что еще помню)
вот первый был как раз "почему так долго считает количество в группах"... подключился к базе своей прогой (не нашол там никакого подобия QA, после скачал TOAD стороннюю программу)
и сам поделал запросы (очень долго) вида
select count(*) from table1 и (на 90 тыс ~ 3сек/mssql ~ 0.001 сек)
select * from table1 where GroupID = 1 (похоже да? ;) естесственно сразу проверил индекс есть.
причем это былобы неважно, но у них в списках товара при переходе с поля на поле есть инфа о группе в которую он включен (количество)... листало удручающе медленно (сек четыре между записями), и именно похоже изза подобного запроса.

почему долго выгружает товар для передачи... т.е. очень долго - 90тыс гдето 45-50 мин. для сравнения наша самая древняя 7мин подобное же количество, поновее на MSSQL 2-3 мин, даже 1С (самая тормозная у нас, да и вообще наверное ;) и то быстрее.
опять же вопроса бы не возникло если бы они не выпячивали "у нас самая быстрая самая крутая база - оракл, поэтому с вашими даже сравнивать нельзя. надо срочно ваше выкидывать и переходить на наше..."

и там более к самой программе вопросы чем к ораклу. (при сканировании бвркода сканеров настроенным не буквенный префикс программа выдавала AV хотя в настройках стояло префикс откидывать...)

ну вот, сначала по телефону мне говорили "у вас не настроен/неправильно установлен оракл..." (8i кстати). да я ж не спорю я его первый раз ставил и насколько понял система неоправданно усложнена. (специально? чтобы еще на за курсы обучения ему платить?). ну это их служба поддержки была, и судя по скучающим голосам проблема эта была не новой. а когда дошло до начальства (те кто знал что это больше им надо а не нам) выслали двух спецов. в общем мы с ними мило поговорили о крутости оракла и правильной установки (исключительно на сервер специально для него) но ни решить проблемы ни обьяснить почему они эти спецы не смогли... обещали разобраться на месте и уехали... навсегда. (обещали позвонить если что решится в любом случае) не позвонили.
пришло время решений, а проблема так и висела в воздухе....в обшем несостоялось партнерство, а с тех пор у меня "осадочек" от самого "крутого" sql сервера. но я допускаю, что там было чтото не то, и на самом деле в руках настоящих специалистов он и показывает чудеса скорости... но зачем же так усугублять то? почему оптимальные настройки не сделать "по умолчанию"? если они есть. зачем быть спецом пользователю? который должен просто поставить и работать...

Особенно странно это select count(*) from table1 и (на 90 тыс ~ 3сек/mssql ~ 0.001 сек)

Кстати у нас пропиареные спецы хотели поставить его, мол круто, но когда просчитали стоимость владения прослезились и протрезвили, поставили MSSQL

2[32] Anatoly Podgoretsky © (28.10.05 09:59)
Остается только удивляться как удается Ораклу оставаться одной из самых крупных (и успешных) ИТ компаний в мире. Наверное только из-за пиара. 8-)

Sergey13 © (28.10.05 10:32) [33]
Ну очень хороший пиар (в наше время), а в более давнее и альтернативы не было, ведь у Микрософта в то время не было серьезной базы, рост начался с версии 2000, и тут они одинаковы, кроме стоимости владения. Тоже самое относится например и к Адобе, в должное время и дальше постоянный агресивный маркетинг. Кроме того надо учесть особенности крупных американских корпораций, которым поддержка и решения важнее качества продукта. Просчеты некоторых компаний, которые делают дистрибутивы менее 200 мбайт (по мнению корпоративных покупателей, продукт с меньшем размером можно и не рассматривать, это не программа). Не стоит также забывать про узкую специализацию и многие другие вещи.

2 [34] Anatoly Podgoretsky © (28.10.05 11:22)
Интересно, а на какой релиз Оракла у вас считалась стоимость владения? Мое ИМХО, что SE One для масштаба группы/небольшого предприятия - с головой хватит в 90% случаев. А стОит это 5000$ - неограниченная или 200$ юзерская лицензия.

sniknik © (28.10.05 9:34) [30]
Мдя, сравнивать на примитивных запросах. Вот два аналогичных запроса (формируются программно), размер запроса около 10 кб. На Oracle отрабатывает мгновенно (0,02 с) на миллионных таблицах. Остальные серверы (в том числе и MS SQL) на таких запросах тупят по несколько секунд.

2 by © (28.10.05 0:30) [28]

>> А индексы строит не пробовали?
Уточняю.
в запросах вида
select * from TABLE1 where ID = 1
Где ID - единственное поле PK

2[37] Fay © (28.10.05 13:21)
Такое возможно если в таблице очень мало записей и проще считать их все, чем читать сначала индекс, а потом данные. В общем случае ФС не будет.

Андрей Жук © (28.10.05 12:23) [36]
я сравнивал то, на чем тормозила (по моему мнению) прога которую я тестировал. если неправильно... ну спецы должны были меня разубедить (действием, т.е. сделать так чтобы листание в их программе было адекватным). но они только репы почесали, на мои сравнения и сказали разберемся...

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

Какую технологию для доступа к данным выбрать ? Найти похожие ветки