а может кто-нибудь поделиться инфой что он применяет для :
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.