[Comm] Выбор СУБД

[Comm] Выбор СУБД

[Михаил Пожидаев]

Здравствуйте.
Подскажите, можно ли при работе с базой данных совместить сервер, 
установленный на Linux, с клиентом для Windows.
Какую СУБД для этого лучше выбрать?
ODBC не хотелось бы использовать.
-- 
С уважением, Михаил Пожидаев.

Re: [Comm] Выбор СУБД

[Ilya Palagin]

Михаил Пожидаев wrote:
> Здравствуйте.
> Подскажите, можно ли при работе с базой данных совместить сервер, 
> установленный на Linux, с клиентом для Windows.
> Какую СУБД для этого лучше выбрать?
> ODBC не хотелось бы использовать.

1.Если вам не надо привязывать базу к каким-либо приложениям,
простейший вариант - CGI.
2.Если нужно взаимодействие, лучше пойти на сайты, скажем, MySQL и 
PostgreSQL
и посмотреть разделы API и Clients, может, и найдете что-нибудь под ваши 
требования.

Re: [Comm] Выбор СУБД

[Leonid B. Sysoletin]

23 Ноябрь 2002 13:32, Михаил Пожидаев написал:
> Подскажите, можно ли при работе с базой данных совместить сервер,
> установленный на Linux, с клиентом для Windows.
> Какую СУБД для этого лучше выбрать?
> ODBC не хотелось бы использовать.

Ответ на первую часть - можно.
Ответ на вторую - зависит от задачи.
А почему ODBC не катит?

-- 
Л. Сысолетин,
webmaster@unicon-ms.ru
[Team Ёжики-рулез!] [Team Котёнки на солярке] [Team Берегите букву "ё"!]

За последствия пуговиц прачечная ответственности не несет.

Re: [Comm] Выбор СУБД

[Vitaly Lugovsky]

On Sat, 23 Nov 2002, Михаил Пожидаев wrote:

> Здравствуйте.
> Подскажите, можно ли при работе с базой данных совместить сервер, 
> установленный на Linux, с клиентом для Windows.
> Какую СУБД для этого лучше выбрать?
> ODBC не хотелось бы использовать.

 И у Oracle, и у PostgreSQL, и даже у MySQL есть клиентские
библиотеки под Win32. Это если не считать всяких там JDBC...

Re: [Comm] Выбор СУБД

[Михаил Пожидаев]

Leonid B. Sysoletin пишет:
> 23 Ноябрь 2002 13:32, Михаил Пожидаев написал:
> 
>>Подскажите, можно ли при работе с базой данных совместить сервер,
>>установленный на Linux, с клиентом для Windows.
>>Какую СУБД для этого лучше выбрать?
>>ODBC не хотелось бы использовать.
> 
> 
> Ответ на первую часть - можно.
> Ответ на вторую - зависит от задачи.
> А почему ODBC не катит?
> 

Она, мне кажется, чрезмерно навороченной.
Хотелось бы найти простое, компактное решение.

-- 
С уважением, Михаил Пожидаев.

Re: [Comm] Выбор СУБД

[Vitaly Lugovsky]

On Sat, 23 Nov 2002, Михаил Пожидаев wrote:

> > Ответ на первую часть - можно.
> > Ответ на вторую - зависит от задачи.
> > А почему ODBC не катит?
> 
> Она, мне кажется, чрезмерно навороченной.
> Хотелось бы найти простое, компактное решение.

 А какие требования к клиентским приложениям?

Re: [Comm] Выбор СУБД

[Михаил Пожидаев]

Vitaly Lugovsky пишет:
> On Sat, 23 Nov 2002, Михаил Пожидаев wrote:
> 
> 
>>>Ответ на первую часть - можно.
>>>Ответ на вторую - зависит от задачи.
>>>А почему ODBC не катит?
>>
>>Она, мне кажется, чрезмерно навороченной.
>>Хотелось бы найти простое, компактное решение.
> 
> 
>  А какие требования к клиентским приложениям?

Свои приложения я планирую создавать под MS Visual C++, используя 
MFC для программирования интерфейса, предварительно сделав 
несколько заготовок для элементов управления.
Хотелось бы, чтобы клиентская часть СУБД пристыковывалась к моему 
приложению и не требовала бы установки или настройки каких-либо 
компонентов ОС. Приложение должно легко переносится с одного 
компьютера на другой.

-- 
С уважением, Михаил Пожидаев.

Re: [Comm] Выбор СУБД

[Vitaly Lugovsky]

On Sat, 23 Nov 2002, Михаил Пожидаев wrote:

> >  А какие требования к клиентским приложениям?
> 
> Свои приложения я планирую создавать под MS Visual C++,

 О, ужас!!!

> используя  MFC для программирования интерфейса,

 Ужас, ужас, ужас!

 Чем Tk не угодил? Или ну хотя бы wxWindows? Неужели
так хочется иметь геморрой? Даже Жаба с JDBC да Swing-ом
была бы значительно менее мазохистским инструментом.

> предварительно сделав 
> несколько заготовок для элементов управления.

 Это что касается GUI. Я так и не услышал требований
к интерфейсу с СУБД - возможности использования нативных для
данной СУБД фичей vs. возможность смены СУБД без извращений в области
интерфейса, корректность отработки странненьких типов данных, 
производительность, и всё такое прочее. Именно этими критериями
руководствуются при выборе интерфейса.

> Хотелось бы, чтобы клиентская часть СУБД пристыковывалась к моему 
> приложению и не требовала бы установки или настройки каких-либо 
> компонентов ОС.

 То есть, драйверов ODBC ставить не хочется. Тогда - нативный интерфейс 
лучше. Рекомендую тогда PostgreSQL - его libpq - вещь более-менее 
кошерная, не то, что ужасный, монстрообразный OCI8. Да и врапперы для
C++ имеются в наличии (как и биндинги почти ко всему, что дышит, включая
Python, Tcl, Perl).

> Приложение должно легко переносится с одного 
> компьютера на другой.

 Вот с JDBC - це не проблема.

Re: [Comm] Выбор СУБД

[Ruslan N. Balkin]

On Sat, 23 Nov 2002 19:46:08 +0600
Михаил Пожидаев wrote:

> Хотелось бы, чтобы клиентская часть СУБД пристыковывалась к моему 
> приложению и не требовала бы установки или настройки каких-либо 
> компонентов ОС. Приложение должно легко переносится с одного 
> компьютера на другой.
Для mysql, наверное mysql++. Поищите в Интернете, я не помню URL.
Для postgres - вроде бы тоже была библиотека, и вроде бы даже работала в
WIN32, по крайней мере у меня собирался под WIN32 psql.exe, ODBC драйвер и
библиотека.

А что касается переносимости - так Вам ODBC и нужен, по-моему.
Производительность упадет процентов на 10 - максимум. При установке
программы требуется всего лишь установить ODBC-драйвер. При таком способе и
программа у вас покомпактнее получится.

На мой взгляд, ODBC вовсе не зло.

-- 
С уважением,
Балькин Руслан.

Re: [Comm] Выбор СУБД

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

> Здравствуйте.
> Подскажите, можно ли при работе с базой данных совместить сервер, 
> установленный на Linux, с клиентом для Windows.
> Какую СУБД для этого лучше выбрать?

Если клиенты только Windows - наверное лучше FireBird.
Если сложная база и/или клиенты еще и на других системах будут - PostgreSQL.
-- 

With Best Regards, Maxim Tyurin
mailto: MrKooll@mail.ru
JID:	MrKooll@jabber.pibhe.com
			

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re[2]: [Comm] ÷ÙÂÏÒ óõâä

[Sergey Krivulja]

Hello Maxim,

Monday, November 25, 2002, 12:48:00 PM, you wrote:

>> Здравствуйте.
>> Подскажите, можно ли при работе с базой данных совместить сервер, 
>> установленный на Linux, с клиентом для Windows.
>> Какую СУБД для этого лучше выбрать?

MT> Если клиенты только Windows - наверное лучше FireBird.
MT> Если сложная база и/или клиенты еще и на других системах будут - PostgreSQL.
Можно и под WIN приладить PostgreSQL.
Большой проблемы нет. Достаточно cygwin поставить.
-- 
Best regards,
 Sergey                            mailto:skrivulja@erec.ru

Re: Re[2]: [Comm] Выбор СУБД

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

> MT> Если клиенты только Windows - наверное лучше FireBird.
> MT> Если сложная база и/или клиенты еще и на других системах будут - PostgreSQL.
> Можно и под WIN приладить PostgreSQL.
> Большой проблемы нет. Достаточно cygwin поставить.

Я не про то. Firebird - маленькая и очень стабильная СУБД.
Но по фичам отстает от PostgreSQL.
И, самое главное, не умеет отдавать результат в кодировке нужной
клиенту, а если все клиенты под виндой - в 1251 работает отлично.
-- 

With Best Regards, Maxim Tyurin
mailto: MrKooll@mail.ru
JID:	MrKooll@jabber.pibhe.com
			

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] Выбор СУБД

[Прокопьев Евгений]

Михаил Пожидаев пишет:

> Здравствуйте.
> Подскажите, можно ли при работе с базой данных совместить сервер,
> установленный на Linux, с клиентом для Windows.
> Какую СУБД для этого лучше выбрать?
> ODBC не хотелось бы использовать.

Firebird

Клиент - 3 файла рядом с exe (реестр трогать не обязятельно), в особо 
тяжелых случаях, когда не надо отображать системных сообщений об 
ошибках, хватает и одного. Подробнее - Install FAQ на www.ibase.ru

Для MSVC можно писать на его API, а можно иcпользовать обертки для C++ 
или препроцессор для С - подробнее там же

-- 
С уважением, Прокопьев Евгений

Re: [Comm] Выбор СУБД

[Михаил Пожидаев]

Прокопьев Евгений пишет:
> Михаил Пожидаев пишет:
> 
>> Здравствуйте.
>> Подскажите, можно ли при работе с базой данных совместить сервер,
>> установленный на Linux, с клиентом для Windows.
>> Какую СУБД для этого лучше выбрать?
>> ODBC не хотелось бы использовать.
> 
> 
> Firebird
> 
> Клиент - 3 файла рядом с exe (реестр трогать не обязятельно), в особо 
> тяжелых случаях, когда не надо отображать системных сообщений об 
> ошибках, хватает и одного. Подробнее - Install FAQ на www.ibase.ru
> 
> Для MSVC можно писать на его API, а можно иcпользовать обертки для C++ 
> или препроцессор для С - подробнее там же
> 

Спасибо за все ответы, я определился.

-- 
С уважением, Михаил Пожидаев.

Re: Re[2]: [Comm] Выбор СУБД

[Sanja Byelkin]

Hi!

On Mon, Nov 25, 2002 at 01:11:34PM +0200, Maxim Tyurin wrote:
> > MT> Если клиенты только Windows - наверное лучше FireBird.
> > MT> Если сложная база и/или клиенты еще и на других системах будут - PostgreSQL.
> > Можно и под WIN приладить PostgreSQL.
> > Большой проблемы нет. Достаточно cygwin поставить.
> 
> Я не про то. Firebird - маленькая и очень стабильная СУБД.
> Но по фичам отстает от PostgreSQL.
> И, самое главное, не умеет отдавать результат в кодировке нужной
> клиенту, а если все клиенты под виндой - в 1251 работает отлично.

А не удивительно что я MySQL посоветую? :)

Перекодировка есть.
работает и под Linux и под Windows (без cygwin).
если WEB приложение - то именно под это заточино (например query cache).
Есть выбор типа таблиц (транзакционные innodb или очень бустрые MyISAM)
при чем таблицы разных типов можно сочетать в обном запросе
Список можно проболжать. :)

-- 
Regards,
Alexander

Re: Re[2]: [Comm] Выбор СУБД

[Vitaly Lugovsky]

On Mon, 25 Nov 2002, Sanja Byelkin wrote:

> А не удивительно что я MySQL посоветую? :)

 А с каких пор оно стало СУБД? ;)

Re: Re[2]: [Comm] Выбор СУБД

[Maxim Tyurin]

> > А не удивительно что я MySQL посоветую? :)
> 
>  А с каких пор оно стало СУБД? ;)

Сам хотел это написать, но сдержался ;)
-- 

With Best Regards, Maxim Tyurin
mailto: MrKooll@mail.ru
JID:	MrKooll@jabber.pibhe.com
			

Re: [JT] [Comm] Выбор СУБД

[Sanja Byelkin]

On Tue, Nov 26, 2002 at 10:26:41AM +0200, Maxim Tyurin wrote:
> > > А не удивительно что я MySQL посоветую? :)
> > 
> >  А с каких пор оно стало СУБД? ;)
> 
> Сам хотел это написать, но сдержался ;)

С давних :)

Может я не понял но что по вашему там нехватает чтоб быть СУБД?

-- 
Regards,
Alexander

[Comm] Re[2]: [JT] [Comm] Выбор СУБД

[aek]

Hello Sanja,

Tuesday, November 26, 2002, 3:55:08 PM, you wrote:

>> > > А не удивительно что я MySQL посоветую? :)
>> >  А с каких пор оно стало СУБД? ;)
SB> С давних :)
SB> Может я не понял но что по вашему там нехватает чтоб быть СУБД?

Что, уже и транзакции появились???
Или зеркалирование данных на серверах/носителях
хоть в каком нибудь виде, все равно в каком???

-- 
Всех благ!
Анатолий

Re: [JT] [Comm] Выбор СУБД

[Vitaly Lugovsky]

On Tue, 26 Nov 2002, Sanja Byelkin wrote:

> > > > А не удивительно что я MySQL посоветую? :)
> > > 
> > >  А с каких пор оно стало СУБД? ;)
> > 
> > Сам хотел это написать, но сдержался ;)
> 
> С давних :)
> 
> Может я не понял но что по вашему там нехватает чтоб быть СУБД?

 Ну ладно, может оно и СУБД - только если и BerkeleyDB тоже СУБД.
Но никак не РСУБД. И, если честно, я вообще не вижу никакой
ниши для MySQL. Не представляю, где его можно было бы эффективно 
использовать...

Re: [JT] [Comm] Выбор СУБД

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

> > >  А с каких пор оно стало СУБД? ;)
> > 
> > Сам хотел это написать, но сдержался ;)
> 
> С давних :)
> 
> Может я не понял но что по вашему там нехватает чтоб быть СУБД?

Хранимых процедур (желательно на нескольких языках), несколько видов
изоляции транзакций, транзакции "только для чтения", UDF, ...

Может многое уже и появилось, но ИМХО это приделывание крыльев к
паровозу. Мускуль - это очень быстрый и стабильный сервер таблиц и от
сложных вложенных запросов очень любит задумываться. 

-- 

With Best Regards, Maxim Tyurin
mailto: MrKooll@mail.ru
JID:	MrKooll@jabber.pibhe.com
			

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[Comm] Re[2]: [JT] [Comm] Выбор СУБД

[Mikhail Ramendik]

Hello Vitaly,

Tuesday, November 26, 2002, 12:29:09 PM, you wrote:

VL>  Ну ладно, может оно и СУБД - только если и BerkeleyDB тоже СУБД.
VL> Но никак не РСУБД. И, если честно, я вообще не вижу никакой ниши
VL> для MySQL. Не представляю, где его можно было бы эффективно
VL> использовать...

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

-- 
Best regards,
 Mikhail                            mailto:mr@ramendik.ru

Re: [Comm] Re[2]: [JT] [Comm] Выбор СУБД

[Alexander Bokovoy]

On Tue, Nov 26, 2002 at 04:27:57PM +0700, aek wrote:
> Hello Sanja,
> 
> Tuesday, November 26, 2002, 3:55:08 PM, you wrote:
> 
> >> > > А не удивительно что я MySQL посоветую? :)
> >> >  А с каких пор оно стало СУБД? ;)
> SB> С давних :)
> SB> Может я не понял но что по вашему там нехватает чтоб быть СУБД?
> 
> Что, уже и транзакции появились???
> Или зеркалирование данных на серверах/носителях
> хоть в каком нибудь виде, все равно в каком???
И то, и другое. Вы давно на него смотрели?
-- 
/ Alexander Bokovoy
---
Insomnia isn't anything to lose sleep over.

Re: [JT] [Comm] Выбор СУБД

[Sanja Byelkin]

Доброго времени суток!

On Tue, Nov 26, 2002 at 11:36:04AM +0200, Maxim Tyurin wrote:
> > > >  А с каких пор оно стало СУБД? ;)
> > > 
> > > Сам хотел это написать, но сдержался ;)
> > 
> > С давних :)
> > 
> > Может я не понял но что по вашему там нехватает чтоб быть СУБД?
> 
> Хранимых процедур (желательно на нескольких языках), несколько видов
> изоляции транзакций, транзакции "только для чтения", UDF, ...
> 
> Может многое уже и появилось, но ИМХО это приделывание крыльев к
> паровозу. Мускуль - это очень быстрый и стабильный сервер таблиц и от
> сложных вложенных запросов очень любит задумываться. 

Но под определение СУБД попадает всеравно.
И перечисленное вами не есть необходимое для управление базой данных (у
людей разные запросы да и даже база данных не обязательно реляционная и с
сервером, COBOL в некотором роде тоже СУБД).
Ну а на счет крыльев это думаю ваше личное мнение не основанное на знании
внутренностей MySQL, или я ошибся?
UDF там живут давно. Уровни изоляции сейчас Heikki в innodb доделал.
Подзапросы тоже уже доступны для попробовать в 4.1, правда я еще не брался
совсем за оптимизацию но в следующем месяце должен приступить.
Хранимые процедуры будут в 5й версии при чем ожидается как интерфейс к
различным языкам так и стандарт SQL99 (это не просто планы - люди уже
работают 5.0 версия еще не публичная но уже есть). Не понимаю почему
развитие продукта воспринимается вами как "приделывание крыльев".

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

-- 
Regards,
Alexander

Re: [Comm] Re[2]: [JT] [Comm] Выбор СУБД

[Vitaly Lugovsky]

On Tue, 26 Nov 2002, Mikhail Ramendik wrote:

> VL>  Ну ладно, может оно и СУБД - только если и BerkeleyDB тоже СУБД.
> VL> Но никак не РСУБД. И, если честно, я вообще не вижу никакой ниши
> VL> для MySQL. Не представляю, где его можно было бы эффективно
> VL> использовать...
> 
> Да в нагруженных Инет-магахинах его гоняют, где практически
> одномоментные элементарные действия, зато скорость надо.

 Занафиг? Лучше трёхуровневку, второй уровень - кэш для шустрости,
первый - настоящая РСУБД для надёжности и удобства.

Re: [Comm] Re[2]: [JT] [Comm] Выбор СУБД

[Sanja Byelkin]

Доброе время суток!

On Tue, Nov 26, 2002 at 04:27:57PM +0700, aek wrote:
> Hello Sanja,
> 
> Tuesday, November 26, 2002, 3:55:08 PM, you wrote:
> 
> >> > > А не удивительно что я MySQL посоветую? :)
> >> >  А с каких пор оно стало СУБД? ;)
> SB> С давних :)
> SB> Может я не понял но что по вашему там нехватает чтоб быть СУБД?
> 
> Что, уже и транзакции появились???

Транзакции есть очень давно (это типы таблиц innodb (с row locking) и bdb (с
page locking) я бы советовал первые если надо трарнзакции и по скорости и по
навороченности).


> Или зеркалирование данных на серверах/носителях
> хоть в каком нибудь виде, все равно в каком???

На счет этого вопроса я не очень понял, что имелось ввиду - но отвечу как
понял:
 Есть репликации master -> N * slave . Можно сделать и двухсторонюю
репликацию, но на нее специальным образом надо составлять запросы, чтобы не
было конфликтов. Репликация Master -> slave используется как для повышения
надежности так и для повышения производительности. (это все относится к
кластеризации - но понятие кластеризации очень размыто (я имею ввиду СУБД)
так что я пользуюсь термином MySQL).
 Если вы про дублирование баз на носителях - то тут только аппаратные RAID
массивы или сделанные ОС т.е. внешние. Что впрочем и более надежно (не мои
слова прочел в какойто книге по ORACLE но с ними согласен).

-- 
Regards,
Alexander

Re: [JT] [Comm] Выбор СУБД

[Ilya Palagin]

Sanja Byelkin wrote:
...
> Я не sales-man и красиво говорить не умею и красивых сравнений делать не
> буду, но кажется на вас в большой степени повляли эмоции и вы преувеличиваете.
> Я конечно не думаю что вас переубедил, но пердлогаю эту тему закрыть.
> 
Заявления вроде "mysql - не СУБД" обычно возникают под влиянием желания
раскинуть пальцы - типа, "у меня даже телефонная книжка на оракле бегает"

[Comm] Re[2]: [Comm] Re[2]: [JT] [Comm] Выбор СУБД

[Mikhail Ramendik]

Hello Vitaly,

Tuesday, November 26, 2002, 1:41:30 PM, you wrote:

VL> On Tue, 26 Nov 2002, Mikhail Ramendik wrote:

>> VL>  Ну ладно, может оно и СУБД - только если и BerkeleyDB тоже СУБД.
>> VL> Но никак не РСУБД. И, если честно, я вообще не вижу никакой ниши
>> VL> для MySQL. Не представляю, где его можно было бы эффективно
>> VL> использовать...
>> 
>> Да в нагруженных Инет-магахинах его гоняют, где практически
>> одномоментные элементарные действия, зато скорость надо.

VL>  Занафиг? Лучше трёхуровневку, второй уровень - кэш для шустрости,
VL> первый - настоящая РСУБД для надёжности и удобства.

Чем больше уровней, тем больше дырок для багов в настройке. Поэтому
если для задачи ничего больше "сервера таблиц" не надо - его и
используют. Кстати и меньше процессорного ресурса жрёт (при большой
нагрузке - актуально).

-- 
Best regards,
 Mikhail                            mailto:mr@ramendik.ru

Re: [Comm] Re[2]: [JT] [Comm] Выбор СУБД

[Sanja Byelkin]

Hi!

On Tue, Nov 26, 2002 at 01:04:43PM +0300, Mikhail Ramendik wrote:
> Hello Vitaly,
> 
> Tuesday, November 26, 2002, 12:29:09 PM, you wrote:
> 
> VL>  Ну ладно, может оно и СУБД - только если и BerkeleyDB тоже СУБД.
> VL> Но никак не РСУБД. И, если честно, я вообще не вижу никакой ниши
> VL> для MySQL. Не представляю, где его можно было бы эффективно
> VL> использовать...
> 
> Да в нагруженных Инет-магахинах его гоняют, где практически
> одномоментные элементарные действия, зато скорость надо.

Да - основная направленность конечно WEB приложения.
Могу добавить что сайты с динамическим содержимым (извлекаемым из базы, где
выдается много одинаковых (имеется ввиду одинаковый текст запроса с
точностью до байта) запросов) в сочетании с query cache вообще 
должны быть очень быстрыми (это один из примеров направленности MySQL на
WEB)

Но не только, я слышал о многих пременениях и вне WEB не всегда ж из пушки 
по воробьям стрелять (я имею ввиду ORACLE), BTW MySQL и не позиционируется
как конкурент последнего.

-- 
Regards,
Alexander

Re: [JT] [Comm] Выбор СУБД

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

> > Хранимых процедур (желательно на нескольких языках), несколько видов
> > изоляции транзакций, транзакции "только для чтения", UDF, ...
> > 
> > Может многое уже и появилось, но ИМХО это приделывание крыльев к
> > паровозу. Мускуль - это очень быстрый и стабильный сервер таблиц и от
> > сложных вложенных запросов очень любит задумываться. 
> 
> Но под определение СУБД попадает всеравно.
> И перечисленное вами не есть необходимое для управление базой данных (у
> людей разные запросы да и даже база данных не обязательно реляционная и с
> сервером, COBOL в некотором роде тоже СУБД).
> Ну а на счет крыльев это думаю ваше личное мнение не основанное на знании
> внутренностей MySQL, или я ошибся?
> UDF там живут давно. Уровни изоляции сейчас Heikki в innodb доделал.
> Подзапросы тоже уже доступны для попробовать в 4.1, правда я еще не брался
> совсем за оптимизацию но в следующем месяце должен приступить.
> Хранимые процедуры будут в 5й версии при чем ожидается как интерфейс к
> различным языкам так и стандарт SQL99 (это не просто планы - люди уже
> работают 5.0 версия еще не публичная но уже есть). Не понимаю почему
> развитие продукта воспринимается вами как "приделывание крыльев".

Потому что MySQL ценится одним - скоростью простых выборок на простых
базах. Приделывание новых фич - сделает его более
громоздким. PostgreSQL, Oracle, DB2 тоже не стоят на месте и не стоит
мускулю за ними гоняться по кол-ву фич. У него своя ниша.
-- 

With Best Regards, Maxim Tyurin
mailto: MrKooll@mail.ru
JID:	MrKooll@jabber.pibhe.com
			

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [JT] [Comm] Выбор СУБД

[W.Kondratev]

Maxim Tyurin wrote:

>Потому что MySQL ценится одним - скоростью простых выборок на простых
>базах. Приделывание новых фич - сделает его более
>громоздким. PostgreSQL, Oracle, DB2 тоже не стоят на месте и не стоит
>мускулю за ними гоняться по кол-ву фич. У него своя ниша.
>  
>
Меня всегда удивляло, почему в подобных перечнях (за несколько последних 
лет
я повидал их десятки) - всегда отсутствует IB Database (Interbase, 
Firebird). Прямо
заговор какой-то. А ведь очень достойная СУБД. Хотя бы упоминания. :)

Re: [Comm] Re[2]: [Comm] Re[2]: [JT] [Comm] Выбор СУБД

[Vitaly Lugovsky]

On Tue, 26 Nov 2002, Mikhail Ramendik wrote:

> VL>  Занафиг? Лучше трёхуровневку, второй уровень - кэш для шустрости,
> VL> первый - настоящая РСУБД для надёжности и удобства.
> 
> Чем больше уровней, тем больше дырок для багов в настройке.

 Ничего подобного. Гораздо больше дырок, когда вся логика зашита в 
клиентскую часть. И уж совершенно непредсказуемые последствия, когда 
несколько клиентов начинают толпиться вместе. В особо тяжелых случаях и 
транзакции не спасают - требуются более интеллектуальные блокировки, что и 
выполняется на промежуточном уровне.

Re: [JT] [Comm] Выбор СУБД

[Sanja Byelkin]

Привет!

Обещал не отвечать но все же отвечу.

On Tue, Nov 26, 2002 at 01:32:58PM +0200, Maxim Tyurin wrote:
[skip]
> > работают 5.0 версия еще не публичная но уже есть). Не понимаю почему
> > развитие продукта воспринимается вами как "приделывание крыльев".
> 
> Потому что MySQL ценится одним - скоростью простых выборок на простых
> базах. Приделывание новых фич - сделает его более
> громоздким. PostgreSQL, Oracle, DB2 тоже не стоят на месте и не стоит
> мускулю за ними гоняться по кол-ву фич. У него своя ниша.

Значит остальныи развиватся можно а MySQL нельзя? :)

А по сути вопроса - если интересно загляните внутрь mysqld (ну хотя бы
sql/sql_parser.cc (mysql_execute_command) или 
sql/sql_select.cc (handle_select)) и вы увидите, что простые запросы 
обрабатываются по другим веткам - отдельно от сложных. Т.е. ваше 
беспокойство, что добавление новых функций приведет к замедлению всех
запросов необосновано.

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

-- 
Regards,
Alexander

[Comm] Re[2]: [Comm] Re[2]: [JT] [Comm] Выбор СУБД

[aek]

Hello Alexander,

Tuesday, November 26, 2002, 5:14:05 PM, you wrote:

>> Что, уже и транзакции появились???
>> Или зеркалирование данных на серверах/носителях
>> хоть в каком нибудь виде, все равно в каком???

AB> И то, и другое. Вы давно на него смотрели?

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

-- 
Всех благ!
Анатолий

[Comm] Re[xxx]: Выбор СУБД

[Dmytro O. Redchuk]

On Wed, 27 Nov 02, at 10:15, aek (aek) wrote:
 > Hello Alexander,
 > 
 > Tuesday, November 26, 2002, 5:14:05 PM, you wrote:
 > 
 > >> Что, уже и транзакции появились???
 > >> Или зеркалирование данных на серверах/носителях
 > >> хоть в каком нибудь виде, все равно в каком???
 > 
 > AB> И то, и другое. Вы давно на него смотрели?
 > 
 > В прошлом году проходил обучение. Один из курсов
 > задевал краешком MySQL. Преподаватель говорил
 > что пока транзакций в нем нет.
 > Если отстал от жизни, извиняйте.

В MySQL транзакции *точно* есть :)
Проверял.

(для BDB и InnoDB, кажется -- может, и еще что-то)
 
 > 
 > -- 
 > Всех благ!
 > Анатолий

-- 
  _,-=._              /|_/|
  `-.}   `=._,.-=-._.,  @ @._,
     `._ _,-.   )      _,.-'
        `    G.m-"^m`m'        Dmytro O. Redchuk

Re: [JT] [Comm] Выбор СУБД

[Прокопьев Евгений]

W.Kondratev wrote:

> Меня всегда удивляло, почему в подобных перечнях (за несколько последних 
> лет
> я повидал их десятки) - всегда отсутствует IB Database (Interbase, 
> Firebird). Прямо
> заговор какой-то. А ведь очень достойная СУБД. Хотя бы упоминания. :

Аналогично.

Есть фичи типа нескольких транзакций с разными параметрами в одном 
подключениии или НОРМАЛЬНАЯ реализация селективных процедур, которые во 
ВСЕХ прочих СУБД просто отсутствуют. А я себе уже не представляю, как 
без этого жить.

Re: [Comm] Выбор СУБД

[Alexei Takaseev]

On Mon, 25 Nov 2002 11:48:00 +0200
Maxim Tyurin <MrKooll@TDR.PIBHE.com> wrote:

> > Здравствуйте.
> > Подскажите, можно ли при работе с базой данных совместить
> > сервер, установленный на Linux, с клиентом для Windows.
> > Какую СУБД для этого лучше выбрать?
> 
> Если клиенты только Windows - наверное лучше FireBird.

FireBird проседает при множествах INSERT'ов. Просто оторопь
берет.

> Если сложная база и/или клиенты еще и на других системах будут
> - PostgreSQL.-- 

Зачем так сурово? Есть же ODBC.

Re: [Comm] Выбор СУБД

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

> > > Здравствуйте.
> > > Подскажите, можно ли при работе с базой данных совместить
> > > сервер, установленный на Linux, с клиентом для Windows.
> > > Какую СУБД для этого лучше выбрать?
> > 
> > Если клиенты только Windows - наверное лучше FireBird.
> 
> FireBird проседает при множествах INSERT'ов. Просто оторопь
> берет.

Не нужно commit после каждой вставки делать :)
Как "множество INSERT'ов" вставка миллиона записей подходит?
Работает и не при

> > Если сложная база и/или клиенты еще и на других системах будут
> > - PostgreSQL.-- 
> 
> Зачем так сурово? Есть же ODBC.

ODBC не причем. Просто PostgreSQL умеет отдавать запросы в разных
кодировках (кому кои, кому 1251, ...), а Firebird не умеет, но в 1251
работает хорошо. Да и при сложных базах UDF много нужно делать :(
-- 

With Best Regards, Maxim Tyurin
mailto: MrKooll@mail.ru
JID:	MrKooll@jabber.pibhe.com
			

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]