Я недавно начал программировать на Дельфи.
До сих пор не доводилось работать с базами.
Но вот сейчас наступило время — нужно выбрать БД для своей программы.
Поделитесь плз опытом: какую БД используете Вы, и чем это объясняется.
И на какой базе предложили бы мне остановиться.

Здравствуйте, Аноним, Вы писали:

А>Я недавно начал программировать на Дельфи.
А>До сих пор не доводилось работать с базами.
А>Но вот сейчас наступило время — нужно выбрать БД для своей программы.
А>Поделитесь плз опытом: какую БД используете Вы, и чем это объясняется.

я использую mysql потому что мне за это платят

А>И на какой базе предложили бы мне остановиться.

если тебе никто пока не платит
для начала остановись на access
проще access только мясорубка

Здравствуйте, Аноним, Вы писали:

А>И на какой базе предложили бы мне остановиться.

"я использую mysql потому что мне за это платят" — это неплохой и точный ответ, лучший из возможных.

База выбирается исходя из задачи и предполагаемых условий разработки/эксплуатации. По Вашему письму совершенно невозможно предположить, какая база будет им соответствовать (и будете ли Вы соответствовать этой базе).

В использовании для себя, в обучении, принципиальной разницы нет. Разве что, я бы предложил не думать о настольных и маломощных БД — чтобы не формировать плохих привычек, которые придется исправлять в серьезной работе. Возможно, стоит порекомендовать Interbase — он довольно стандартен, то есть с него будет относительно легко переходить на что-то другое.

Здравствуйте, vvaizh, Вы писали:

V>я использую mysql потому что мне за это платят

Мне нужно писать прогу которая работает с собственной БД на Дельфи, с mysql это возможео. (с mysql не знаком совершенно)

А>>И на какой базе предложили бы мне остановиться.

V>если тебе никто пока не платит
V>для начала остановись на access
V>проще access только мясорубка

Собственно 75% работы уже сделана на access (!).

Здравствуйте, vvaizh, Вы писали:

V>я использую mysql потому что мне за это платят

Мне нужно писать прогу которая работает с собственной БД на Дельфи, с mysql это возможео. (с mysql не знаком совершенно)

А>>И на какой базе предложили бы мне остановиться.

V>если тебе никто пока не платит
V>для начала остановись на access
V>проще access только мясорубка

Собственно 75% работы уже сделана на access (!).

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

А>>И на какой базе предложили бы мне остановиться.

S>"я использую mysql потому что мне за это платят" — это неплохой и точный ответ, лучший из возможных.

S>База выбирается исходя из задачи и предполагаемых условий разработки/эксплуатации. По Вашему письму совершенно невозможно предположить, какая база будет им соответствовать (и будете ли Вы соответствовать этой базе).

S>В использовании для себя, в обучении, принципиальной разницы нет. Разве что, я бы предложил не думать о настольных и маломощных БД — чтобы не формировать плохих привычек, которые придется исправлять в серьезной работе. Возможно, стоит порекомендовать Interbase — он довольно стандартен, то есть с него будет относительно легко переходить на что-то другое.

для Delphi Interbase достаточно неплохой вариант, так как достаточно родной..
я вот только не очень понял, какие "нехорошие" навыки прививает Access?
если правильно к нему подходить и работать как с "большой субд", максимально
стараясь напрягать SQL, а не перебирать resultset-s в циклах, то никаких
привычек нехороших не будет. более того очень скоро настанет желание большего..

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, vvaizh, Вы писали:

V>>я использую mysql потому что мне за это платят

А>Мне нужно писать прогу которая работает с собственной БД на Дельфи, с mysql это возможео. (с mysql не знаком совершенно)
возможно
более того, в варианте "embeded" исчезают доп. расходы на межпрограммное взаимодействие
то есть это наиболее быстрое решение
(правда не в курсе, есть ли компоненты позволяющие цеплять embedded к Delphi)

А>>>И на какой базе предложили бы мне остановиться.

вообще для Delphi роднее Interbase/Firebird, но опять же все зависит от задач и текущего состояния

V>>если тебе никто пока не платит
V>>для начала остановись на access
V>>проще access только мясорубка

А>Собственно 75% работы уже сделана на access (!).

тогда чем она не устраивает?
вообще по такому случаю проще перескочить на jet или msdn, это у спецов спроси..

Здравствуйте, vvaizh, Вы писали:


V>>>если тебе никто пока не платит
V>>>для начала остановись на access
V>>>проще access только мясорубка

А>>Собственно 75% работы уже сделана на access (!).

V>тогда чем она не устраивает?
V>вообще по такому случаю проще перескочить на jet или msdn, это у спецов спроси..

Потому что БД будет содержать очень разнообразную инфу, которая будет использоваться для разнообразных задач:
Формирование различных документов, типа договоров, справок (реализовано см.выше),
Будет использоваться интерактивно: телефонный справочник+звонок
Будет использоваться совершенно другими программами для извлечения нужных данных
Т.е. одна глобальная база
и очень много задач, соответственно программ

Здравствуйте, vvaizh, Вы писали:

V>для Delphi Interbase достаточно неплохой вариант, так как достаточно родной..

Не думаю, что есть принципиальная разница. Дельфа "равноудаленная" — разве что поддержку paradox можно вынести в "родные", и то как раз это — решение сомнительной полезности.

V>я вот только не очень понял, какие "нехорошие" навыки прививает Access?
V>если правильно к нему подходить и работать как с "большой субд", максимально
V>стараясь напрягать SQL, а не перебирать resultset-s в циклах, то никаких
V>привычек нехороших не будет. более того очень скоро настанет желание большего..

Если правильно подходить, можно научиться работать и без компьютера — только по книгам. Но правильно подходить в неподходящем инструменте — сложно.

В Access, насколько я знаю, отсутствуют триггера и хранимый код — что уже очень серьезный момент. Вопросы блокировок, формирования id-шников, метаинформация — судя по вопросам, которые задавали бывшие access-овцы, тоже не все "как у больших". Никогда не слышал применительно к Access термин "план запроса"

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, vvaizh, Вы писали:


V>>>>если тебе никто пока не платит
V>>>>для начала остановись на access
V>>>>проще access только мясорубка

А>>>Собственно 75% работы уже сделана на access (!).

V>>тогда чем она не устраивает?
V>>вообще по такому случаю проще перескочить на jet или msdn, это у спецов спроси..

А>Потому что БД будет содержать очень разнообразную инфу, которая будет использоваться для разнообразных задач:
А>Формирование различных документов, типа договоров, справок (реализовано см.выше),
А>Будет использоваться интерактивно: телефонный справочник+звонок
А>Будет использоваться совершенно другими программами для извлечения нужных данных
А>Т.е. одна глобальная база
А>и очень много задач, соответственно программ

в следующий раз пиши "Нужее клиент сервер а не файл сервер"
люди начнут к тебе относиться уважительнее

ok, тогда насколько я понимаю "бескровнее" будет переход на
msdn это уже более полноценная многоклиентская СУБД
количество соединений ИМХО там несколько тоже ограничено
но зато с неё уже совсем нет никаких проблем перейти на MSSQL

а вооще тут уже пора при таких раскладах задумываться о лицензионности,
выделенном сервере и т.д.
не уверен что технология MS ыобще тут будет лучше.
стоит посмотреть в сторону открытых СУБД (тот же Firebird если мускул не нравится)

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, vvaizh, Вы писали:

V>>для Delphi Interbase достаточно неплохой вариант, так как достаточно родной..

S>Не думаю, что есть принципиальная разница. Дельфа "равноудаленная" — разве что поддержку paradox можно вынести в "родные", и то как раз это — решение сомнительной полезности.

V>>я вот только не очень понял, какие "нехорошие" навыки прививает Access?
V>>если правильно к нему подходить и работать как с "большой субд", максимально
V>>стараясь напрягать SQL, а не перебирать resultset-s в циклах, то никаких
V>>привычек нехороших не будет. более того очень скоро настанет желание большего..

S>Если правильно подходить, можно научиться работать и без компьютера — только по книгам. Но правильно подходить в неподходящем инструменте — сложно.

S>В Access, насколько я знаю, отсутствуют триггера и хранимый код — что уже очень серьезный момент. Вопросы блокировок, формирования id-шников, метаинформация — судя по вопросам, которые задавали бывшие access-овцы, тоже не все "как у больших". Никогда не слышал применительно к Access термин "план запроса"

все это так, но никаких лишних навыков это не формирует..
полезных конечно не формирует то же
но при озвученных вопросах человек видимо не сразу и так до них дойдет..

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

хм. вот именно никаких кривых решений я и не услышал..
ессно как только чел. чувствует что возникает надобность в
"кривых" решениях стоит задумываться о более дорогих технологиях
однако есть целый большой класс задач для которых и от аксесса никаких
кривых решений не требовалось довольно долго

Здравствуйте, vvaizh, Вы писали:

V>все это так, но никаких лишних навыков это не формирует..

Увы, не так. Формирует совершенно лишний навык решать эти задачи неправильным способом. К примеру — буквально вчера, человек, пришедший с фокса, здесь же спрашивал "а где в дельфе функция "сгенерировать id-шник". А то в фоксе была очень удобная — от таймера, а в дельфе, похоже, придется свою писать".

V>ессно как только чел. чувствует что возникает надобность в
V>"кривых" решениях стоит задумываться о более дорогих технологиях

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

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

Не спорю — без этого можно обойтись. Теоретически. Практически — лучше сразу учиться делать правильно на инструменте, где такая возможность предусмотрена и описана в документации. В данном случае я просто опираюсь на личную статистику — проблем, которые видел у людей, начинавших с оракла, по сравнению с проблемами людей, начинавших с файл-серверных и настольных БД.

Здравствуйте, vvaizh, Вы писали:

V>вообще по такому случаю проще перескочить на jet или msdn, это у спецов спроси..

а при чем здесь msdn? и, кстати, для доступа к Access испольутся всё тот же jet

> Я недавно начал программировать на Дельфи.
> До сих пор не доводилось работать с базами.
> Но вот сейчас наступило время — нужно выбрать БД для своей программы.
> Поделитесь плз опытом: какую БД используете Вы, и чем это объясняется.
> И на какой базе предложили бы мне остановиться.

Бери MSDE — это копия большого брата т.е. MS SQL на нем можно решать задачи любой сложности объем данных которых не превышает 2 ГБ . Дальше просто ограничение MSDE срабатывает. На нем научишся красиво программировать — гарантированно выучишь SQL (без этого можно даже и не заикаться о том что ты умеешь программить БД), а как только поймешь что такое SQL — сразу поймешь что все остальные настольные БД — это ... вообщем ненадо их использовать изначально.

>> Я недавно начал программировать на Дельфи.
>> До сих пор не доводилось работать с базами.
>> Но вот сейчас наступило время — нужно выбрать БД для своей программы.
>> Поделитесь плз опытом: какую БД используете Вы, и чем это объясняется.
>> И на какой базе предложили бы мне остановиться.

Это был мой вопрос!
Наверное требуется еще кое что уточнить!
В принцепе я уже делал некоторые попытки создать БД.
И пришел к выводу что работа с BDE меня не совсем устраивает (не буду углубляться в подробности).
Поддержка SQL считаю обязательным(в прЫнцпе есть некоторый опыт, малееенький правда, но все же).
Использование лицензированных продуктов, тем более для начинания... ну сами понимаенте, да?
И еще такое небольшое условие — должна быть не особо громозкая вещь.

_>Бери MSDE — это копия большого брата т.е. MS SQL на нем можно решать задачи любой сложности объем данных которых не превышает 2 ГБ . Дальше просто ограничение MSDE срабатывает. На нем научишся красиво программировать — гарантированно выучишь SQL (без этого можно даже и не заикаться о том что ты умеешь программить БД), а как только поймешь что такое SQL — сразу поймешь что все остальные настольные БД — это ... вообщем ненадо их использовать изначально.

Беру!! Только подскажите где!

И еще одно маленькое условие...(что то много условий получается, однако!! )
Возможно в дальнейшем создание программ на C# — так что хотелось бы этот момент учесть!

Ну вот пожалуй все.

Ну и повторю один вопрос на который не нашел ответ: Поделитесь плз опытом: какую БД используете Вы, и чем это объясняется.
Вот теперь пожалуй все.
Спасибо за внимание!

> Использование лицензированных продуктов, тем более для начинания... ну сами понимаенте, да?
> И еще такое небольшое условие — должна быть не особо громозкая вещь.
Ну если говорить о лицензионности то тем кто купил SQL сервер — разрешается распространять со своими продуктами и MSDE .
Насчет громоздкости? Не скажу что он громоздкий Основной объем на диске у тебя будут занимать БД а не сервер .

> _>Бери MSDE — это копия большого брата т.е. MS SQL на нем можно решать задачи любой сложности объем данных которых не превышает 2 ГБ . Дальше просто ограничение MSDE срабатывает. На нем научишся красиво программировать — гарантированно выучишь SQL (без этого можно даже и не заикаться о том что ты умеешь программить БД), а как только поймешь что такое SQL — сразу поймешь что все остальные настольные БД — это ... вообщем ненадо их использовать изначально.
>
> Беру!! Только подскажите где!

Где? — Да в комплекте Office XP уже идет MSDE. Наверняка в более поздних версиях он тоже включен.
Ну или как вариант — на базаер покупаем "лицензионный" MS SQL сервере и на диске берем инсталл.

А еще можно скачать 3-й сервис пак для MSDE — он фактически и есть инсталл — там прямо в доке к сервис паку написано что можно инсталлироваться смело .

Правда еще нужны будут клиент тулз Ну это ты уже сам как нибудь талант прояви.

> И еще одно маленькое условие...(что то много условий получается, однако!! )
> Возможно в дальнейшем создание программ на C# — так что хотелось бы этот момент учесть!
Сам я на шарпе не писал еще, но тоже планирую и здается мне что у MS SQL продуктов никаких проблем с Шарпами не бдует

Здравствуйте, mvg_first, Вы писали:

_>Где? — Да в комплекте Office XP уже идет MSDE. Наверняка в более поздних версиях он тоже включен.
Точно.
Установил, даже!
Кстати для тех кто будет идтиТЬ по этому пути: инсталл и в Office 2000 (\SQL\X86\SETUP, нужно запускать SETUPSQL.EXE).
Надеюсь что я прав!

_>Сам я на шарпе не писал еще, но тоже планирую и здается мне что у MS SQL продуктов никаких проблем с Шарпами не бдует
Это хорошо!!

Токо вот никаких доков инете не могу найти...
Если есть дайте плз ссылки!!

Здравствуйте, ilsy, Вы писали:

I>Здравствуйте, mvg_first, Вы писали:

_>>Где? — Да в комплекте Office XP уже идет MSDE. Наверняка в более поздних версиях он тоже включен.
I>Точно.
I>Установил, даже!
I>Кстати для тех кто будет идтиТЬ по этому пути: инсталл и в Office 2000 (\SQL\X86\SETUP, нужно запускать SETUPSQL.EXE).
I>Надеюсь что я прав!

_>>Сам я на шарпе не писал еще, но тоже планирую и здается мне что у MS SQL продуктов никаких проблем с Шарпами не бдует
I>Это хорошо!!

I>Токо вот никаких доков инете не могу найти...
I>Если есть дайте плз ссылки!!

здесь много информации по этой теме.

> Токо вот никаких доков инете не могу найти...
> Если есть дайте плз ссылки!!
Лучше бы тебе раздобыть компашку с инсталлом полновесного MS SQL, с него можно запросто установить такую штуку как Client Tools, вот в нее входит чудесная вещица — Books Online — там есть все про синтаксис и не только про него касаемо MS SQL и прочих сервисов.

Здравствуйте, vvaizh, Вы писали:

V>ok, тогда насколько я понимаю "бескровнее" будет переход на
V>msdn это уже более полноценная многоклиентская СУБД
V>количество соединений ИМХО там несколько тоже ограничено
V>но зато с неё уже совсем нет никаких проблем перейти на MSSQL

на msdn переходить точно не стоит

а может кто-нибудь поделиться инфой что он применяет для :
1)включения MSDE в дистрибутив рапространяемого приложения
2)включения базы данных в иоговую инсталяшку
3)как прикрутить Enterprise Manager для MDSE
4)что нибудь типа ErWin для MSDE

Здравствуйте, Аноним, Вы писали:

А>Я недавно начал программировать на Дельфи.
А>До сих пор не доводилось работать с базами.
А>Но вот сейчас наступило время — нужно выбрать БД для своей программы.
А>Поделитесь плз опытом: какую БД используете Вы, и чем это объясняется.
А>И на какой базе предложили бы мне остановиться.

Выбираем сравниваем апельсины с лампочками...

Ты в начале скажи какой круг задач тебе необходимо возложить на СУБД, а затем пости свой вопрос.

Если с СУБД предполагается работа нескольких юзверей используй клиент-серверную архитектуру, в противном случае клиент-файловую(т.е. desktop'овую).

Из всех файл-серверных лучше MS Access не знаю
С клиент-серверными дело по хуже, тут надо отталкиваться от того под какой ОС будет работать СУБД (ставить Oracle на Win32 смысла нет, ставь на Win32 MS SQL Server 7/2000 — проще и лучше), аппаратное обеспечение сервера и клиентов(концепция тонкий клиент-толстый сервер — большая часть бизнес логики выполняется на сервере или тонкий сервер-толстый клиент — наоборот), использование в интернете или интранете(free ware soft — здесь лучший MySQL)

А вообще это головная боль сис.админа или админа Б.Д., но не программиста.
Программер должен знать библиотеки для взаимодействия с СУБД(ADO, ODBC, OLE DB)

Мой совет — не зацикливаться на конкретной СУБД (Oracle или MS SQL Server), т.к. приложения нужно писать в 3-х уровневой архитектуре при этой архитектуре СУБД хранит только данные — дешевле как разработчику, так и заказчику.

Здравствуйте, white_znake, Вы писали:

_>Из всех файл-серверных лучше MS Access не знаю

Хм. Ладно, допустим.

_>С клиент-серверными дело по хуже,

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

_>тут надо отталкиваться от того под какой ОС будет работать СУБД (ставить Oracle на Win32 смысла нет,

Ну-ну. Жаль, что реальные заказчики об этом не знают

_>А вообще это головная боль сис.админа или админа Б.Д., но не программиста.
_>Программер должен знать библиотеки для взаимодействия с СУБД(ADO, ODBC, OLE DB)

Верно. Если, конечно, программер не собирается работать на серьезном уровне.

_>Мой совет — не зацикливаться на конкретной СУБД (Oracle или MS SQL Server), т.к. приложения нужно писать в 3-х уровневой архитектуре при этой архитектуре СУБД хранит только данные — дешевле как разработчику, так и заказчику.

Хм. Отдел сказок, как известно, всегда этажом выше.

Здравствуйте, Lloyd, Вы писали:

V>>но зато с неё уже совсем нет никаких проблем перейти на MSSQL

L>на msdn переходить точно не стоит

Заметил, что из всех названных СУБД не была названа Linter. Причём её русскоязычную версию свободно (использовать в Демо-варианте, для обучения демо-режима будет достаточно) мона скачать с ftp://relex.ru/ — 30 Мб. Там же можно найти и кучу русских доков по ней и по SQL.

Здравствуйте, Жмур, Вы писали:
Ж>Заметил, что из всех названных СУБД не была названа Linter. Причём её русскоязычную версию свободно (использовать в Демо-варианте, для обучения демо-режима будет достаточно) мона скачать с ftp://relex.ru/ — 30 Мб. Там же можно найти и кучу русских доков по ней и по SQL.

А в чем приемущество Linter-а... для создания нового проекта (кроме как наличие русской документациии?)

Здравствуйте, white_znake, Вы писали:
_>Из всех файл-серверных лучше MS Access не знаю
_>ставить Oracle на Win32 смысла нет,

Ты считаешь что ветка Oracle под Win32 не стабильна?
или тут речь о цене решения?

Здравствуйте, PPA, Вы писали:

PPA>А в чем приемущество Linter-а... для создания нового проекта (кроме как наличие русской документациии?)

Я не спец по СУБД, но насколько я знаю, Линтер ничем не уступает буржуйским MS SQL и Oracle (в чём-то он лучше, в чём-то хуже, также как и указанные СУБД). Вроде бы, основных преимущества, из-за которых его выбирает крупные компании — это невысокая стоимость (по сравнению с Ораклом и MS SQL) и надёжность.

Здравствуйте, <Аноним>, Вы писали:

А>И на какой базе предложили бы мне остановиться.

а можно подойти к выбору с учетом необходимости продавать свой труд
связка оракла + жавы сможет тебя неплохо прокормить (или оракл + делфи)
или M$ SQL + VB.NET
а с интебейз предложений на рынке труда будет поменьше

можно конечно изучить и Linter — пусть работадатели помучаются

Здравствуйте, Sergey__, Вы писали:

S__>а можно подойти к выбору с учетом необходимости продавать свой труд
S__>связка оракла + жавы сможет тебя неплохо прокормить (или оракл + делфи)
S__>или M$ SQL + VB.NET
S__>а с интебейз предложений на рынке труда будет поменьше

Гм... Написал простенький телефонный справочник (стоимость работ пусть будет 100 у.е.) а в нагрузку заставил купить Oracle за несколько тысяч у.е...
Неплохо выглядит Особенно со стороны заказчика Так что лучше учить SQL как таковой, а уж потом заморачиваться на конкретные реализации от MS,Oracle и т.п.

Здравствуйте, DarkMaster, Вы писали:

DM>Гм... Написал простенький телефонный справочник (стоимость работ пусть будет 100 у.е.) а в нагрузку заставил купить Oracle за несколько тысяч у.е...

А ты в прайсы посмотри Oracle SE One стоит около $1000. А его хватит куда больше, чем для "простенького телефонного справочника" — это, собственно, практически полноценный Oracle. Навскидку — не поддерживаются Partitining, OLAP и еще что-то из опций. Точнее физически их подключить можно, но тогда техподдержка пошлет по известному адресу.

DM>Неплохо выглядит Особенно со стороны заказчика Так что лучше учить SQL как таковой, а уж потом заморачиваться на конкретные реализации от MS,Oracle и т.п.

Хороший совет, только практически нереализуемый. Потому как учиться исключительно по книгам — не есть оптимум, а чистый ANSI SQL, да на нормальной платформе.. имхо не так-то просто найти.

Если бы я сейчас мог "вернуться и начать с нуля" — я бы сел учить, параллельно держа книги по ANSI SQL и по выбранному диалекту. То есть — осваивать и при этом подсматривать "как оно по стандарту".

Здравствуйте, Жмур, Вы писали:

Ж>Я не спец по СУБД, но насколько я знаю, Линтер ничем не уступает буржуйским MS SQL и Oracle (в чём-то он лучше, в чём-то хуже, также как и указанные СУБД). Вроде бы, основных преимущества, из-за которых его выбирает крупные компании — это невысокая стоимость (по сравнению с Ораклом и MS SQL) и надёжность.

Вряд ли так считает кто-нибудь, кроме авторов. Простые цифры: на форумах sql.ru Linter упоминается в 6 из 118.000 тем. Соответственно, есть подозрение, что его вообще никто не выбирает — по крайней мере, у нас.

Здравствуйте, Softwarer, Вы писали:

S>Вряд ли так считает кто-нибудь, кроме авторов. Простые цифры: на форумах sql.ru Linter упоминается в 6 из 118.000 тем. Соответственно, есть подозрение, что его вообще никто не выбирает — по крайней мере, у нас.

Согласен, что упоминаний о нём в рунете очень мало, в сети вообще на порядки меньше, чем MS SQL и Oracle, но это не значит, что он хуже — просто у него рекламы меньше (возьми тот же Postgre — не молодой, но просто не особенно раскученный). Я, например, о нём раньше вообще не слышал — и был дико удивлён, что это российская СУБД. Но его используют многие крупные западные компании.

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, DarkMaster, Вы писали:

DM>>Гм... Написал простенький телефонный справочник (стоимость работ пусть будет 100 у.е.) а в нагрузку заставил купить Oracle за несколько тысяч у.е...

S>А ты в прайсы посмотри Oracle SE One стоит около $1000. А его хватит куда больше, чем для "простенького телефонного справочника" — это, собственно, практически полноценный Oracle. Навскидку — не поддерживаются Partitining, OLAP и еще что-то из опций. Точнее физически их подключить можно, но тогда техподдержка пошлет по известному адресу.

Мне, как заказчику нужен только телефонный справочник. Откуда (да и зачем?) мне вообще знать, что можно будет что-то еще впоследствии наворотить бог знает что еще? Задачи с упором на будущее даются либо внутри корпорации, либо сторонним производителям, которые уже никак не учаться а
четко представляют все плюсы и минусы выбранной БД.

DM>>Неплохо выглядит Особенно со стороны заказчика Так что лучше учить SQL как таковой, а уж потом заморачиваться на конкретные реализации от MS,Oracle и т.п.

S>Хороший совет, только практически нереализуемый. Потому как учиться исключительно по книгам — не есть оптимум, а чистый ANSI SQL, да на нормальной платформе.. имхо не так-то просто найти.

S>Если бы я сейчас мог "вернуться и начать с нуля" — я бы сел учить, параллельно держа книги по ANSI SQL и по выбранному диалекту. То есть — осваивать и при этом подсматривать "как оно по стандарту".

Согласен. Без знания основ никуда не денешься, а уходить на какую-то платформу (т.е. учитываеть ее особенности) все равно придется, если не ставить перед собой цель написать полностью портируемую на разные сервера серверную часть (ANSI все-таки все производители стараются более-менне следовать).

Здравствуйте, Жмур, Вы писали:

Ж>Согласен, что упоминаний о нём в рунете очень мало, в сети вообще на порядки меньше, чем MS SQL и Oracle, но это не значит, что он хуже — просто у него рекламы меньше (возьми тот же Postgre — не молодой, но просто не особенно раскученный). Я, например, о нём раньше вообще не слышал — и был дико удивлён, что это российская СУБД. Но его используют многие крупные западные компании.

Тот же Postgre и не совсем чета озвученной парочке. И не делая поиска можно сказать, что упоминается он на порядок-другой почаще, нежели Linter. А сделав поиск, так и сказать — на порядок.

Мы говорим не о домохозяйках и телерекламе, а о сообществе достаточно компетентных ИТ-шников, к которым в принципе принадлежат и авторы этого Linter-а. Мы говорим о форумах, в которых свободно обсуждаются достаточно экзотические СУБД. И если линтер там практически не известен и практически не интересен — сомневаюсь, что он входит в пятерку или в десятку ведущих мировых продуктов.

Здравствуйте, DarkMaster, Вы писали:

DM>Мне, как заказчику нужен только телефонный справочник. Откуда (да и зачем?) мне вообще знать, что можно будет что-то еще впоследствии наворотить бог знает что еще? Задачи с упором на будущее даются либо внутри корпорации, либо сторонним производителям, которые уже никак не учаться а
DM>четко представляют все плюсы и минусы выбранной БД.

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

А "заказчик на один телефонный справочник" — это уже почти утопия. И делая "легкий" выбор сегодня стоит четко осознавать — завтра ты или кто-нибудь другой будет приделывать сюда еще несколько модулей. Либо у заказчика образуется замечательный зоопарк из десятка "телефонных справочников".

DM>Согласен. Без знания основ никуда не денешься, а уходить на какую-то платформу (т.е. учитываеть ее особенности) все равно придется, если не ставить перед собой цель написать полностью портируемую на разные сервера серверную часть (ANSI все-таки все производители стараются более-менне следовать).

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

Здравствуйте, Softwarer, Вы писали:

S>Мы говорим не о домохозяйках и телерекламе, а о сообществе достаточно компетентных ИТ-шников, к которым в принципе принадлежат и авторы этого Linter-а. Мы говорим о форумах, в которых свободно обсуждаются достаточно экзотические СУБД. И если линтер там практически не известен и практически не интересен — сомневаюсь, что он входит в пятерку или в десятку ведущих мировых продуктов.

Блин, мне не до споров. Твоё дело как считать. Хочешь — зайди на http://relexus.com/ там перечислены некоторые из наиболее крупных заказчиков. Просто при том же качестве/возможностях, но меньшей популярности, более дешёвая СУБД. Если стоимость не играет роли, то флаг в руки. Я с не почти работал не с одной из этих СУБД, и я не могу судить о том деталях.

Здравствуйте, Softwarer, Вы писали:

S>Я отнюдь не собираюсь утверждать, будто бы для любой задачи Oracle лучше, скажем, Access — это не так. Но в то же время факт в том — что я хотел подчеркнуть, что от "тяжелых" решений сегодня не удастся беспредметно отмахиваться — они уже далеко не такие "тяжелые", как представляются.

А я что, отмахиваюсь от тяжелых решений? Наоборот — призываю не отмахиваться и от легких решений Речь идет о выборе БД начинающим программером, которому чуть выше предложили попутно еще и оценить возможность зарабатывания денег, так? Сразу же на ум приходят ShareWare программы, которые не являются коробочными продуктами и для которых тяжелый сервер явно избыточен. Вот я свое мнение и высказал

S>А "заказчик на один телефонный справочник" — это уже почти утопия.

Угу. Обьем продажи мультимедийных энциклопедий растет с каждым днем. А теперь давайте включим в дистрибутив еще и Оракла — жуть получается не правда ли (я не говорю уже об обьеме дистрибутива, необходимости настройки и стоимости)?

S>И делая "легкий" выбор сегодня стоит четко осознавать — завтра ты или кто-нибудь другой будет приделывать сюда еще несколько модулей. Либо у заказчика образуется замечательный зоопарк из десятка "телефонных справочников".

Опять-таки — если твое приложение — корпоративное, и создается "на вырост" или рост потенциально возможен.
В общем каждому серверу — свою нишу в зависимости от применения и приложений.

Здравствуйте, DarkMaster, Вы писали:

DM>Гм... Написал простенький телефонный справочник (стоимость работ пусть будет 100 у.е.) а в нагрузку заставил купить Oracle за несколько тысяч у.е...
а кто тут говорил про телефонный справочник на Oracle ?
фантазируем ?

DM>Неплохо выглядит Особенно со стороны заказчика
DM>Так что лучше учить SQL как таковой, а уж потом заморачиваться на конкретные реализации от MS,Oracle и т.п.
а ежели тебе заказали "простенький телефонный справочник" — то с точки зрения рапростронения его идеально сделать под JET (ADO + .mdb)
например будет работать с CD без всякой инсталяции и вообще ничего не записывая на HDD

а ежели ты его сделаешь, например под embedded Firebird 1.5, стараясь придерживаться SQL92 и макс задействовать хранимые процедуры,
то если воникнет неободимость развернуть многопользовательский вариант — не придется вообще ничего переделывать (а инсталяция упрощается до XCOPY)
да и тут ведь говорилось про обучение а у Access есть небольшие проблемы со stored procedure что делает его непригодным для обучения

Здравствуйте, Жмур, Вы писали:
Ж>Я не спец по СУБД, но насколько я знаю, Линтер ничем не уступает буржуйским MS SQL и Oracle (в чём-то он лучше, в чём-то хуже, также как и указанные СУБД). Вроде бы, основных преимущества, из-за которых его выбирает крупные компании — это невысокая стоимость (по сравнению с Ораклом и MS SQL) и надёжность.
СУБД, которые не упомянуты на www.tpc.org, вообще не стоит рассматривать для OLTP приложений Enterprize уровня.

Здравствуйте, DarkMaster, Вы писали:

DM>Здравствуйте, Softwarer, Вы писали:

S>>Я отнюдь не собираюсь утверждать, будто бы для любой задачи Oracle лучше, скажем, Access — это не так. Но в то же время факт в том — что я хотел подчеркнуть, что от "тяжелых" решений сегодня не удастся беспредметно отмахиваться — они уже далеко не такие "тяжелые", как представляются.
DM>А я что, отмахиваюсь от тяжелых решений?

Вы дали информацию об их тяжести (в данном случае — цене) в несколько раз отличающуюся от истинной. Имхо это именно отмахивание — то есть принятие решения не на основании объективной информации, а по слухам.

DM>Речь идет о выборе БД начинающим программером, которому чуть выше предложили попутно еще и оценить возможность зарабатывания денег, так? Сразу же на ум приходят ShareWare программы, которые не являются коробочными продуктами и для которых тяжелый сервер явно избыточен. Вот я свое мнение и высказал

Зарабатывание денег начинающим программером на ShareWare программах — это даже не утопия, это ненаучная фантастика.

DM>Угу. Обьем продажи мультимедийных энциклопедий растет с каждым днем. А теперь давайте включим в дистрибутив еще и Оракла — жуть получается не правда ли (я не говорю уже об обьеме дистрибутива, необходимости настройки и стоимости)?

Нет, жуть не получается — это опять из серии "по слухам". У меня, например, лежит один изрядно незаполненный сидишник, с которого Oracle 9 устанавливается, не задавая ни единого вопроса.

Впрочем, я бы в такой ситуации включил в дистибутив Firebird — если его лицензия это позволяет. Или одно из аналогичных по классу решений.

S>>И делая "легкий" выбор сегодня стоит четко осознавать — завтра ты или кто-нибудь другой будет приделывать сюда еще несколько модулей. Либо у заказчика образуется замечательный зоопарк из десятка "телефонных справочников".
DM>Опять-таки — если твое приложение — корпоративное, и создается "на вырост" или рост потенциально возможен.

Из всех проектов, в которых я участвовал — и халтур, и серьезных — я помню единственный проект, по которому заказчик не просил через какое-то время доработки. Куда чаще серьезные доработки начинались еще раньше, чем сдавалась первая версия.

DM>В общем каждому серверу — свою нишу в зависимости от применения и приложений.

Безусловно. Но если говоришь о некоей "общей" нише, стартовом, обобщенном решении — я бы не стал относить туда ни Access, ни настольные БД вообще. Сегодня это имхо ниша, скажем, для mySQL.

Здравствуйте, Жмур, Вы писали:

Ж>Блин, мне не до споров. Твоё дело как считать. Хочешь — зайди на http://relexus.com/ там перечислены некоторые из наиболее крупных заказчиков. Просто при том же качестве/возможностях, но меньшей популярности, более дешёвая СУБД.

Загляни там в Full Feauture List. Список крайне невелик. О производительности не сказано практически ничего, DWH/OLAP, похоже, нет в принцпипе. В общем, насчет "того же качества/возможностей" — непохоже. Очень непохоже.

Список клиентов у того же MySQL выглядит куда как солиднее. AIRBUS, пожалуй, "потяжелее" питерских авиаторов, а Government of New York, пожалуй, покруче администрации Воронежа.

Сами производители на первое место пихают security. Что само по себе, наверное, неплохо, но заставляет задуматься о наличии прочих качеств.

Судя опять же по фичам — явно планировали заменить Oracle в дешевых сегментах, что-то типа SE версии.

Здравствуйте, Softwarer, Вы писали:

S>Список клиентов у того же MySQL выглядит куда как солиднее. AIRBUS, пожалуй, "потяжелее" питерских авиаторов, а Government of New York, пожалуй, покруче администрации Воронежа.

Хм, и где ты откопал администрацию Воронежа — нашёл, что взять в качестве примера?.. По моему Sony, Panasonic и т.д. покруче будут. Это первое. И второе, я сам сторонник открытого софта — не буду в этом случае спорить. А речь шла не о Мускуле, а MS SQL, Oracle и Linter.

S>Судя опять же по фичам — явно планировали заменить Oracle в дешевых сегментах, что-то типа SE версии.

Возможно.

Здравствуйте, Жмур, Вы писали:

S>>Список клиентов у того же MySQL выглядит куда как солиднее. AIRBUS, пожалуй, "потяжелее" питерских авиаторов, а Government of New York, пожалуй, покруче администрации Воронежа.
Ж>Хм, и где ты откопал администрацию Воронежа — нашёл, что взять в качестве примера?..

Хм. Дык они выставили его одним из ведущих клиентов. У мускуля в этой же нише — администрация Нью-Йорка и еще полтора десятка подобных.

Ж>По моему Sony, Panasonic и т.д. покруче будут.

По-моему, Sony и Panasonic будут примерно того же класса, что и Yamaha, Epson, Fujitsu, Daimler.. Я взял то, что расходится не только по количеству клиентов, но и по качеству — имхо корректный подход, чтобы показать разницу.

Ж> Это первое. И второе, я сам сторонник открытого софта — не буду в этом случае спорить. А речь шла не о Мускуле, а MS SQL, Oracle и Linter.

А зачем их разделять? Это коммерческие продукты, пересекающиеся в некоторой части ценового диапазона. Мускуль выглядит покруче Линтера. Но на одну доску с MS SQL и Oracle его пока еще не ставят — только показывают, что в некоторых случаях он является лучшим выбором.

Здравствуйте, Softwarer, Вы писали:

S>А зачем их разделять? Это коммерческие продукты, пересекающиеся в некоторой части ценового диапазона. Мускуль выглядит покруче Линтера. Но на одну доску с MS SQL и Oracle его пока еще не ставят — только показывают, что в некоторых случаях он является лучшим выбором.

Мне совсем не хочется продолжать этот бестолковый спор — мне не горячо не холодно от того, что ты вбухаешь n-ю сумму в MS SQL или Oracle лишь из-за того, что они более раскученные. Даже ваши серваки будут держать БД на Linter — мне от этого тоже так же... Всё равно решать руководителю компании за что заплатить... или взять левую версию — тогда точно не важно. Так, что давай закончим этот флейм.

Здравствуйте, Softwarer, Вы писали:

S>В Access, насколько я знаю, отсутствуют триггера и хранимый код — что уже очень серьезный момент. Вопросы блокировок, формирования id-шников, метаинформация — судя по вопросам, которые задавали бывшие access-овцы, тоже не все "как у больших". Никогда не слышал применительно к Access термин "план запроса"

Немного поправлю. "хранимый код" в акцесе есть.

Здравствуйте, Softwarer, Вы писали:

S>Список клиентов у того же MySQL выглядит куда как солиднее. AIRBUS, пожалуй, "потяжелее" питерских авиаторов, а Government of New York, пожалуй, покруче администрации Воронежа.

C Воронежем как раз все логично — разработчики-то воронежские.

Здравствуйте, Kupaev, Вы писали:

K>C Воронежем как раз все логично — разработчики-то воронежские.

Так я вроде как в нелогичности и не обвинял. Но как клиент Нью-Йорк все же покруче, имхо.

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, Kupaev, Вы писали:

K>>C Воронежем как раз все логично — разработчики-то воронежские.

S>Так я вроде как в нелогичности и не обвинял. Но как клиент Нью-Йорк все же покруче, имхо.

Там свои такие есть.