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

← →
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 очень бесит.
А индексы строит не пробовали? )

← →
Anatoly Podgoretsky © (2005-10-28 00:45) [29]

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

← →
sniknik © (2005-10-28 09:34) [30]

> А индексы строит не пробовали? )
я с ним не работаю, один раз тока ставил на пару недель потестить одну программу воможных партнеров. ну естественно не очень хорошо его не знаю. но на мои вопросы почему там у них и что, приехали два спеца по ораклу. и надо сказать они тоже не прояснили мне ситуацию (в итоге партнеры не состоялись ;).
а вопросы были простые (то что еще помню)
вот первый был как раз "почему так долго считает количество в группах"... подключился к базе своей прогой (не нашол там никакого подобия 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 сервера. но я допускаю, что там было чтото не то, и на самом деле в руках настоящих специалистов он и показывает чудеса скорости... но зачем же так усугублять то? почему оптимальные настройки не сделать "по умолчанию"? если они есть. зачем быть спецом пользователю? который должен просто поставить и работать...

← →
Anatoly Podgoretsky © (2005-10-28 09:57) [31]

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

← →
Anatoly Podgoretsky © (2005-10-28 09:59) [32]

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

← →
Sergey13 © (2005-10-28 10:32) [33]

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

← →
Anatoly Podgoretsky © (2005-10-28 11:22) [34]

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

← →
Sergey13 © (2005-10-28 11:31) [35]

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

← →
Андрей Жук © (2005-10-28 12:23) [36]

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

← →
Fay © (2005-10-28 13:21) [37]

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

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

← →
Fay © (2005-10-28 13:24) [38]

2 Андрей Жук © (28.10.05 12:23) [36]
Я видел и обратные ситуации, причём чаще.

← →
Sergey13 © (2005-10-28 13:47) [39]

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

← →
sniknik © (2005-10-28 14:24) [40]

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

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

← →
Anatoly Podgoretsky © (2005-10-28 14:34) [41]

Sergey13 © (28.10.05 11:31) [35]
С какой стати ты относишь стоимость лицензии к стоимости владения.

← →
sniknik © (2005-10-28 14:36) [42]

> Где ID - единственное поле PK
а у меня индекс был не ключь, простой. но похоже был такойже полный скан... (я там не знал как план посмотреть, да и сейчас не знаю ;) )

и кстати предвидя... ;о) групп было много, гдето (не вспомню точно) 250-300 т.к. там учет по концевой (группа-подгруппа-еще подгруппа..., всего 6 уровней) на 90тыс товаров. (я просто загрузил первый попавшийся приличный справочник, с реального магазина. а то они нашим боссам на 100-а товарах показывали...)

т.е. там должно было работать по индексу, понятно если бы одна две группы на 90 тыс... тут и полный скан был бы оправдан.

2 Sergey13 © (28.10.05 13:47) [39]
Блин, не надо объяснять мне как пионеру!

40000 записей достаточно для использования индекса

На железо, на разработку, на обслуживание.
Например в известном мне случае, только первые два пункта потянули $2000000 против $2000000 только по первым двум пунктам, а по третьему пункту ситуация еще хуже, 4 администратора vc 1, плюс сопровеждение в два раза дороже.

2 [46] Fay © (28.10.05 15:12)
>Блин, не надо объяснять мне как пионеру!

тогда не надо писать

>Только вот full scan в запросах вида
>select * from TABLE1 where ID = 1 очень бесит.

тут тоже не все пионеры. Если бы это было так вряд ли Оракл был бы Ораклом.

2[47] Anatoly Podgoretsky © (28.10.05 15:13)
Я не зная конечно того случая, но неужели железо+разработка для одной и той же задачи так уж отличаются для Оракл и МС? Не оспариваю, но сомнительно мне. Да и про админов сомнительно как то?

Sergey13 © (28.10.05 15:25) [48]
Не сумлевайся, информации по стоимости владения в Интернете достаточно.
По админам привыкни к тому, что существует понятие узкая специализация и многостаночники. Если у вас в норме что сегодня специалист ремонтирует водопроводный кран, а завтра оптимизирует индексы на сервере, то в других местах это не так и то что стоимость профессионала в Оракле и в MSSQL отличается тоже. Аналогично и по Линукс/Юникс против МС
То что дешево продается, может очень дорого стоить в эксплуатации.
Вот тебе известный пример лазерники дороже чернильных, а вот по эксплуатации строго наоборот. Есть и смешные примеры, когда новый чернильник продается за 600 единиц, а новая чернильника к нему за 630.
В случае сложных систем это наблюдается очень сильно.

2 Sergey13 © (28.10.05 15:25) [48]
>> Если бы это было так вряд ли Оракл был бы Ораклом.
Что "это"? Не думаю, что судьба Oracle зависит от того, что "тут тоже не все пионеры".
Получается, что ты обвиняешь меня во лжи, утверждая, что мои слова могут быть правдой только при условии (Oracle != Oracle).

Следи за словами. Я совершенно не заинтересован в том, чтобы врать на некотором форуме какому-то Sergey13.

2[50] Fay © (28.10.05 17:14)
>Следи за словами.
Аналогично.
Твое утверждение
>Только вот full scan в запросах вида
>select * from TABLE1 where ID = 1 очень бесит.

Есть ложь. У меня например подобный запрос везде показывает INDEX UNIQUE SCAN, что и логично. Почему у тебя идет FS - вопрос не ко мне.

2[52] Anatoly Podgoretsky © (31.10.05 09:53)
Потому тчо он и должен тут быть. Если поле - ПК и есть соответствующий индекс, то надо отдельно стараться, что бы получить другое. 8-)

2[52] Anatoly Podgoretsky © (31.10.05 09:53)
Я предполагаю (процентов на 90), почему у моего оппонента идет ФС. Наверное статистика собиралась один раз несколько лет назад. Вот стоимостной оптимизатор и "заблуждается".

Интересно было бы узнать что вы думаете о MySQL 5 (где хранимки и тригера появились) ? Наверное ничего :)

> стоимость профессионала в Оракле и в MSSQL отличается тоже

Я никак этого не могу понять... Какие-такие профессионалы в оракле?
Чего такого супер-глубинного надо знать, чтобы поддерживать систему на оракле в работоспособном состоянии? Если тебе ее поставили и настроили заказчики - дальше только следи, чтобы аппаратная часть не ломалась.

А сравнивать оракл с MS SQL Server-ом вовсе нелепо! Как можно версионник сравнить с блокировщиком?

Курдль © (31.10.05 14:11) [59]
Оракл тут ни причем, причем только раскрутка, как с СИ
Система должна быть сложной, чтобы обосновать высокие затраты.

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