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

Откуда: Серпухов
Сообщений: 472
AI
s_elected
Все просто клент не нужен вовсе!
Есть компоненты ODAC http://crlab.com/odac/
они умеют соединяться напрямую к БАЗЕ через TCP/IP
OCI не учавствует при таком соединении!

есть версии как для Delphi так и для C++ Builder всех версий.
там все написано

а чтобы окончательно все прояснить по поводу соединения,
то вот ссылка где нормальным английским языком все написано
http://crlab.com/odac/


А если на сервере прописано SQLNET.ENCRYPTION_SERVER = required и заданы алгоритмы шифрования, то работает ли ODAC?


Затрудняюсь ответить так как точно не знаю.
Но думаю что ODAC через OCI работать будет
а в режиме Net (напрямую через TCP/IP) думаю нет
хотя просто нужно потестирывать и убедиться
15 фев 05, 15:12    [1322608]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ODAC Net не поддерживает некоторые функции Net 8. В том числе и шифрование.
15 фев 05, 15:20    [1322637]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
S.PR
Member

Откуда: Минск
Сообщений: 1275
s_elected
Отвечц всем на вопрос "почему компоненты прямого доступа"
Я строю свой софт так:
Есть 1 EXE файл. Он самостоятельно соединяется с БД без каких либо dll или тем более провайдеров! и Выкачивает из базы по мере надобности DLL проекта так как они лежат в BLOB.
т.е. для запуска программы ничего не требуется кроме одого файла exe и настройки подключения. ВСЕ!
Я Убежден что это правильный подход!
При таком подходе администрирование клиенских машин сводится к 0!
И админ занимается сервером.

Из вышеизложенного прошу совета:
К какой из вышеобсуждаемых СУБД есть такие компоненты для Delphi 7?
т.е. без всего коннектятся ! Даже без DLL!
Для MySQL у меня такие есть. называются MYDAC. www.crLab.com

Креативу нет предела ;-)


Подход поддерживаю! У меня аналогичный.
Штук 20 задач крутится для 50 юзеров.
Delphi 7 + dbExpress + FireBird 1.5
15 фев 05, 15:44    [1322727]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
s_elected
Member

Откуда: Серпухов
Сообщений: 472
S.PR
s_elected
Отвечц всем на вопрос "почему компоненты прямого доступа"
Я строю свой софт так:
Есть 1 EXE файл. Он самостоятельно соединяется с БД без каких либо dll или тем более провайдеров! и Выкачивает из базы по мере надобности DLL проекта так как они лежат в BLOB.
т.е. для запуска программы ничего не требуется кроме одого файла exe и настройки подключения. ВСЕ!
Я Убежден что это правильный подход!
При таком подходе администрирование клиенских машин сводится к 0!
И админ занимается сервером.

Из вышеизложенного прошу совета:
К какой из вышеобсуждаемых СУБД есть такие компоненты для Delphi 7?
т.е. без всего коннектятся ! Даже без DLL!
Для MySQL у меня такие есть. называются MYDAC. www.crLab.com

Креативу нет предела ;-)


Подход поддерживаю! У меня аналогичный.
Штук 20 задач крутится для 50 юзеров.
Delphi 7 + dbExpress + FireBird 1.5


Спасибо за поддержку =-)
приятно осознавать что у меня есть единомышленники
15 фев 05, 15:49    [1322751]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
S.PR
Подход поддерживаю! У меня аналогичный.
Штук 20 задач крутится для 50 юзеров.
Delphi 7 + dbExpress + FireBird 1.5

У меня другой подход - использую нормальные средства и при этом тоже нет проблем с установкой. Так одну из программ для 6000 пользователей тоже не нужно устанавливать - достаточно скопировать содержимое каталога и запустить. После этого работает автообновление и т.п., копируются все нужные библиотеки для работы с БД. Такой подход мне нравится больше.
C# + Web Services + ADO.Net + MS SQL2k
15 фев 05, 18:26    [1323066]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
S.PR
Member

Откуда: Минск
Сообщений: 1275
andsm
S.PR
Подход поддерживаю! У меня аналогичный.
Штук 20 задач крутится для 50 юзеров.
Delphi 7 + dbExpress + FireBird 1.5

У меня другой подход - использую нормальные средства и при этом тоже нет проблем с установкой. Так одну из программ для 6000 пользователей тоже не нужно устанавливать - достаточно скопировать содержимое каталога и запустить. После этого работает автообновление и т.п., копируются все нужные библиотеки для работы с БД. Такой подход мне нравится больше.
C# + Web Services + ADO.Net + MS SQL2k


А какой у вас критерий нормальности средств?
15 фев 05, 18:51    [1323138]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
S.PR
А какой у вас критерий нормальности средств?

Критерий нормальности - это использование как можно более производительных с точки зрения скорости разработки инструментов.
Подчеркиваю - именно с точки зрения скорости разработки, а не скорости работы. Инструменты естественно должны удовлетворять и требованиям по производительности, надежности, прочим требованиям ТЗ. Как правило требования к производительности невысокие, и выбор инструментов очень широкий. Например возьмем случай 50 пользователей. Это небольшое количество пользователей. При более-менее неплохой архитектуре БД, пользователи базу сильно загрузить не смогут для большинства типов приложений. Поэтому использовать тут всевозможные компонеты прямого доступа и т.п. оптимизации - считаю это лишним. Хотя плохой архитектурой БД запросто можно добиться того что все будет основательно тормозить. Но если это случится, то причина почти наверняка - плохая архитектура или только БД, или в целом всего приложения. Компоненты прямого доступа и прочие оптимизации могут улучшить ситуацию, но ненамного. Причина в таких случаях не в лишних интерфесных вызовах, а в архитектуре.
Иногда, и я встречался с такими проектами, действительно важна каждая миллисекунда. В этих случаях в ТЗ расписываются требования к времени вызова каждого метода, и т.п. Тогда действительно нужно думать о всевозможных оптимизациях. Но такие проекты встречаются очень нечасто.
15 фев 05, 19:18    [1323223]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
s_elected
Member

Откуда: Серпухов
Сообщений: 472
andsm
Критерий нормальности - это использование как можно более производительных с точки зрения скорости разработки инструментов.
Подчеркиваю - именно с точки зрения скорости разработки, а не скорости работы.

Вы в корне не правы! если мы говорим об ODAC, то я вас уверяю эти компоненты гораздо удобнее!!! И скорочть разработки на них возрастает в 2 а то и в 3 раза! Только одно формирование секций insert update modify что стоит. Я уже не говорю о специальных задачах заранее приготовленных для соответсвующей СУБД. А вот как раз универсальные компоненты тем и ценятся что они универсальные, но в то же время не удобные потому что каждая СУБД имеет особенности!

И выбор компонентов прямого доступа это как раз выбор в сторону удобства разработки а не производительности! С этим трудно поспорить.
Пройдитесь по форумам и почитайте как люди мучаются с ODBC и прочей универсальностью. =-)

Креативу нет предела ;-)
15 фев 05, 23:00    [1323445]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
s_elected
Member

Откуда: Серпухов
Сообщений: 472
andsm
Критерий нормальности - это использование как можно более производительных с точки зрения скорости разработки инструментов.
Подчеркиваю - именно с точки зрения скорости разработки, а не скорости работы.

Вы в корне не правы! если мы говорим об ODAC, то я вас уверяю эти компоненты гораздо удобнее!!! И скорочть разработки на них возрастает в 2 а то и в 3 раза! Только одно формирование секций insert update modify что стоит. Я уже не говорю о специальных задачах заранее приготовленных для соответсвующей СУБД. А вот как раз универсальные компоненты тем и ценятся что они универсальные, но в то же время не удобные потому что каждая СУБД имеет особенности!

И выбор компонентов прямого доступа это как раз выбор в сторону удобства разработки а не производительности! С этим трудно поспорить.
Пройдитесь по форумам и почитайте как люди мучаются с ODBC и прочей универсальностью. =-)

Креативу нет предела ;-)
15 фев 05, 23:02    [1323448]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
автор
Пройдитесь по форумам и почитайте как люди мучаются с ODBC и прочей универсальностью. =-)


Они просто не умеют их готовить :)
15 фев 05, 23:47    [1323470]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
s_elected
Member

Откуда: Серпухов
Сообщений: 472
Alexey Sh
автор
Пройдитесь по форумам и почитайте как люди мучаются с ODBC и прочей универсальностью. =-)


Они просто не умеют их готовить :)


=-))))))))))))) Супер подкол!
16 фев 05, 09:33    [1323806]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
S.PR
Member

Откуда: Минск
Сообщений: 1275
andsm

Критерий нормальности - это использование как можно более производительных с точки зрения скорости разработки инструментов.
Подчеркиваю - именно с точки зрения скорости разработки, а не скорости работы. Инструменты естественно должны удовлетворять и требованиям по производительности, надежности, прочим требованиям ТЗ.


А чем Delphi 7 не угодил?

andsm

Как правило требования к производительности невысокие, и выбор инструментов очень широкий. Например возьмем случай 50 пользователей. Это небольшое количество пользователей. При более-менее неплохой архитектуре БД, пользователи базу сильно загрузить не смогут для большинства типов приложений.


Требования по производительности высокие ВСЕГДА,
в БД это один из важнейших показателей.

andsm

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


Насчет архитектуры - согласен.
16 фев 05, 13:02    [1324529]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
автор
Требования по производительности высокие ВСЕГДА,
в БД это один из важнейших показателей.


Производительность бывает не только у СУБД и приложения, но и у разработчика(индивидуального или команды)
16 фев 05, 13:17    [1324606]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
S.PR
Member

Откуда: Минск
Сообщений: 1275
Alexey Sh
автор
Требования по производительности высокие ВСЕГДА,
в БД это один из важнейших показателей.


Производительность бывает не только у СУБД и приложения, но и у разработчика(индивидуального или команды)

Точна!
16 фев 05, 13:22    [1324645]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
S.PR
Требования по производительности высокие ВСЕГДА,
в БД это один из важнейших показателей.

Не верю. Чаще только кажется что требования высокие, при внимательном изучении оказывается что требования по производительности на самом деле невысокие. И для обеспечения требуемой производительности не нужно заниматься всякими оптимизациями и т.п., нужно лишь как можно быстрее сделать работающую систему.
16 фев 05, 13:47    [1324756]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
S.PR
Member

Откуда: Минск
Сообщений: 1275
andsm
S.PR
Требования по производительности высокие ВСЕГДА,
в БД это один из важнейших показателей.

Не верю. Чаще только кажется что требования высокие, при внимательном изучении оказывается что требования по производительности на самом деле невысокие. И для обеспечения требуемой производительности не нужно заниматься всякими оптимизациями и т.п., нужно лишь как можно быстрее сделать работающую систему.

Это чтобы быстрее деньги получить
и когда другие дяди будут систему поддерживать.
16 фев 05, 13:56    [1324794]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
S.PR
Это чтобы быстрее деньги получить
и когда другие дяди будут систему поддерживать.

Заказчику нужна в первую очередь система решающая его бизнес-проблемы.
То что она будет работать на несколько процентов медленнее или наоборот быстрее, при условии что производительность находится в рамках ТЗ, заказчика не волнует.
Как между собой связана ориентация на скорость разработки (при полном выполнении ТЗ) и поддержка системы не вижу.
16 фев 05, 14:35    [1324933]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
S.PR
Member

Откуда: Минск
Сообщений: 1275
andsm

Заказчику нужна в первую очередь система решающая его бизнес-проблемы.
То что она будет работать на несколько процентов медленнее или наоборот быстрее, при условии что производительность находится в рамках ТЗ, заказчика не волнует.
Как между собой связана ориентация на скорость разработки (при полном выполнении ТЗ) и поддержка системы не вижу.


На первых порах да.
Но если бизнес развивается то увеличиваются и бизнес-проблемы
и объемы данных и количество пользователей.
Становится все более актуальной проблема производительности.
А если изначально не было ставки на производительность, то при поддержке системы оптимизация перерастает в главную проблему,
которая может эту систему вообще завалить.
Конечно все зависит от конкретной задачи задачи.
Я например имею ввиду информационную систему масштаба предприятия.
16 фев 05, 15:35    [1325241]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Не тратьте силы, возьмите молоток потяжелее (с)
Задача выбора СУБД - многокритериальная
16 фев 05, 15:52    [1325337]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
S.PR
На первых порах да.
Но если бизнес развивается то увеличиваются и бизнес-проблемы
и объемы данных и количество пользователей.
Становится все более актуальной проблема производительности.
А если изначально не было ставки на производительность, то при поддержке системы оптимизация перерастает в главную проблему,
которая может эту систему вообще завалить.
Конечно все зависит от конкретной задачи задачи.
Я например имею ввиду информационную систему масштаба предприятия.

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

Сейчас например я в проекте где скорость имеет очень большое значение. В ТЗ прописаны ожидаемые средние времена транзакций, прописана планируемая нагрузка - 10 000 пользователей и 1000 транзакций в секунду в пиковые моменты. СУБД - MS SQL2k. С учетом того что железо для такой задачи будет относительно слабым, здесь нужно думать о скорости. Но для большинства задач с которыми обычно сталкиваются разработчики, думать о процентах скорости не нужно - достаточно построить грамотную архитектуру системы и БД.
16 фев 05, 16:05    [1325388]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32895

Привет, andsm!
Ты пишешь:

andsm
a> Сейчас например я в проекте где скорость имеет очень большое значение.
a> В ТЗ прописаны ожидаемые средние времена транзакций,
a> прописана планируемая нагрузка - 10 000 пользователей

А дворникам компьютеры тоже положены на этом "предприятии"?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

16 фев 05, 16:08    [1325402]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
2 Мимопроходящий : в качестве пользователя может выступать не только дворник, а датчик. например
16 фев 05, 16:14    [1325423]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32895

Привет, Alexey!
Ты пишешь:

Alexey
AS> 2 Мимопроходящий : в качестве пользователя может выступать не только дворник, а датчик. например

Хороший у тебя датчик!
Прямиком к RDBMS подключается.
Без MidleWare!
Чё мелочиться-то?!.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

16 фев 05, 16:17    [1325439]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Формально этот датчик является пользователем (хотя бы с лицензионной точки зрения) независимо от использования MidleWare.
16 фев 05, 16:22    [1325462]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Alexey Sh
2 Мимопроходящий : в качестве пользователя может выступать не только дворник, а датчик. например

В той задаче о которой я написал - пользователи это именно физические лица, а не датчики. Да, бывают и такие задачи.
16 фев 05, 16:23    [1325469]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить