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

Откуда:
Сообщений: 118
Что посоветуете выбрать в качестве СУБД, при седеющих условиях:

1. Программа из ряда трафик менеджеров, т.е. вводятся поступления Х (некоторое множество), затем несколько человек (около 20ти человек по сети) эти поступления списывают, при условии не превышая списаний в подмножестве. Далее на основе этого создание доп. таблиц и отчетов и т.п.
2. Примерный объем данных около 1000 списаний (по 50 множествам) в месяц, объем каждого множества около 50 чисел.

Предварительно АРМ будет писаться на Delphi.

Хотелось бы узнать какие можно использовать СУБД, как бесплатные, так и платные (если предлагаете платную, то озвучьте ориентировочную цену вопроса, на приобретение ПО)
10 май 11, 18:11    [10631207]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Firebird
10 май 11, 18:17    [10631228]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54784

0. То, что есть у заказчика
1. То, что лучше знаешь
2. Первую попавшуюся.

Posted via ActualForum NNTP Server 1.4

10 май 11, 18:24    [10631250]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
K0LbAzzeR
Предварительно АРМ будет писаться на Delphi.


Э-э-э...
Возможно в начале опробовать связку Visual Studio Express C# + ExpressSQL?
Как минимум потом будет возможность мигрировать на MS SQL...

А так...

Если все бесплатно, но геморрно, то Lazarus + PostgreSQL

Если хотите Delphi, то Delphi + Firebird

Если хотите весело и быстро, то Visual FoxPro + MS SQL

Если хотите быстро и грустно, то Access + MS SQL

Если хотите дорого и тяжело, то Java + Oracle

Если хотите весело и бесплатно, то PHP + MySQL

...

Думаю можно продолжить :-)
11 май 11, 07:04    [10632716]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
arni
Member

Откуда: Иваново
Сообщений: 3544
mad_nazgul
Если все бесплатно, но геморрно, то Lazarus + PostgreSQL

Если хотите Delphi, то Delphi + Firebird

Если хотите весело и быстро, то Visual FoxPro + MS SQL

Если хотите быстро и грустно, то Access + MS SQL

Если хотите дорого и тяжело, то Java + Oracle

Если хотите весело и бесплатно, то PHP + MySQL
Вы живете в каком-то розовом мире, где среды разработки, языки программирования и СУБД тасуются как карты. Всегда есть какой-то базис. Обычно это наиболее знакомый язык, для которого выбирается среда, и под задучу в итоге подбирается СУБД. Для мелкого проекта требования к СУБД и необходимые навыки, которые придется усвоить, чтобы выполнять банальные select/insert/update/delete, бесконечно далеки по трудоемкости от изучения новой языковой среды.
11 май 11, 08:45    [10632860]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Слушай меня, браза
Guest
Oracle - без вариантов.
11 май 11, 08:58    [10632889]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
mad_nazgul

Если хотите дорого и тяжело, то Java + Oracle


Думаю можно продолжить :-)

Можно уточнить: Не обязательно Java и поэтому не обязательно тяжело: от Oracle тежелого вроде ниче не придвидится. Наоборот, на всем ЖЦ скорей всего проще: полно фич у Оракла, чтобы разруливать по ходу траблы, которые не удалось предвидеть по тем или иным причинам. Не обязательно дорого: есть даже бесплатные редакции.
11 май 11, 09:50    [10633045]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
mad_nazgul
Если все бесплатно, но геморрно, то Lazarus + PostgreSQL

А что геморного-то?
11 май 11, 10:04    [10633094]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Програмист разумный
Guest
ОКТОГЕН
mad_nazgul
Если все бесплатно, но геморрно, то Lazarus + PostgreSQL

А что геморного-то?

OpenSource - это всегда гемор. По оперделению.
11 май 11, 10:11    [10633144]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
miwaonline
Member

Откуда:
Сообщений: 2249
Програмист разумный
OpenSource - это всегда гемор. По оперделению.

Высечь в камне. На века.

По сабжу лучше всего DS посоветовал.

По связке лазарус + ФБ - под лазарус ФИБов нету. Видел заметки, что кто-то правил их и таки запустил, но проще, думаю, будет стандартные лазаревые компоненты юзать.
11 май 11, 15:41    [10636285]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54784

miwaonline
По связке лазарус + ФБ - под лазарус ФИБов нету.

Зато есть UIB и AnyDAC.

Posted via ActualForum NNTP Server 1.4

11 май 11, 16:06    [10636576]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
arni
Вы живете в каком-то розовом мире, где среды разработки, языки программирования и СУБД тасуются как карты. Всегда есть какой-то базис. Обычно это наиболее знакомый язык, для которого выбирается среда, и под задучу в итоге подбирается СУБД. Для мелкого проекта требования к СУБД и необходимые навыки, которые придется усвоить, чтобы выполнять банальные select/insert/update/delete, бесконечно далеки по трудоемкости от изучения новой языковой среды.


Так я привел самые "ходовые связки".
Причем проверенные на личном опыте.

<:o)
11 май 11, 16:08    [10636593]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
vadiminfo
Можно уточнить: Не обязательно Java и поэтому не обязательно тяжело: от Oracle тежелого вроде ниче не придвидится. Наоборот, на всем ЖЦ скорей всего проще: полно фич у Оракла, чтобы разруливать по ходу траблы, которые не удалось предвидеть по тем или иным причинам. Не обязательно дорого: есть даже бесплатные редакции.


Java - тяжело... ибо клиент на нем...
Oracle - это большой баян с кучей кнопок.
11 май 11, 16:11    [10636614]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
ОКТОГЕН
mad_nazgul
Если все бесплатно, но геморрно, то Lazarus + PostgreSQL

А что геморного-то?


Там гемор в Lazarus.
Ну очень "не стабильная" платформа.
Хотя сейчас в принципе использовать можно.
PostgreSQL - мне нравиться, но можно налететь на проблемы по производительности. Нужен очень тонкий тюнинг.
11 май 11, 16:13    [10636647]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
mad_nazgul
PostgreSQL - мне нравиться, но можно налететь на проблемы по производительности. Нужен очень тонкий тюнинг.
проблемы с производительностью при 1000 записях в месяц? да это в екселе можно спокойно вести
11 май 11, 19:13    [10637932]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
mad_nazgul
Java - тяжело... ибо клиент на нем...

Вообще-то у Оракловых БД клиентов может быть много на разных языках, причем на Джаве может не быть ни одного.

mad_nazgul
Oracle - это большой баян с кучей кнопок.

Не знаю что это означает, но подозреваю, что речь идет о каком-то неудачном студенческом опыте.
Однако, думаю, что СУБД Oracle - удачный выбор, в частности, потому что у него много фич (ручек), позволяющих часто по быстрому разруливать разные требования, появляющиеся у заказчика по ходу или там траблы не предвиденные разработчиками.
Конечно, есть много проггеров готовых дописывать недостающие ф-ии СУБД на клиенте, да и вообще изобретать велосипеды.
Но не у всех же стока рвения. Кому-то проще када СУБД предоставляет по макимому ф-ии по управлению данными. Таким луче кучу фич в СУБД.
11 май 11, 23:19    [10638748]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
vadiminfo
mad_nazgul
Java - тяжело... ибо клиент на нем...

Вообще-то у Оракловых БД клиентов может быть много на разных языках, причем на Джаве может не быть ни одного.


Не спорю.
Чаще всего встречал на Delphi :-)

vadiminfo
Не знаю что это означает, но подозреваю, что речь идет о каком-то неудачном студенческом опыте.


В пору моего студенчества на просторах СНГ об Oracle мало кто знал. :-)

vadiminfo
Однако, думаю, что СУБД Oracle - удачный выбор, в частности, потому что у него много фич (ручек), позволяющих часто по быстрому разруливать разные требования, появляющиеся у заказчика по ходу или там траблы не предвиденные разработчиками.
Конечно, есть много проггеров готовых дописывать недостающие ф-ии СУБД на клиенте, да и вообще изобретать велосипеды.
Но не у всех же стока рвения. Кому-то проще када СУБД предоставляет по макимому ф-ии по управлению данными. Таким луче кучу фич в СУБД.


Вот это и называется "баян с кучей кнопок", когда количество "фич" превышает все разумные пределы. :-)
12 май 11, 06:43    [10639239]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
SergSuper
mad_nazgul
PostgreSQL - мне нравиться, но можно налететь на проблемы по производительности. Нужен очень тонкий тюнинг.
проблемы с производительностью при 1000 записях в месяц? да это в екселе можно спокойно вести


Ну если БД эксплуатируется несколько лет, без администрирования :-)
12 май 11, 06:45    [10639241]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
mad_nazgul
Вот это и называется "баян с кучей кнопок", когда количество "фич" превышает все разумные пределы. :-)

Так тем кто назвал фичи мешают? Тут ждешь каждую новую версию в надежде на новые фичи, а им пределы превышены? Хороши. Ниче не скажешь. В 8 Оракле превышены? А мне теперь после 11 кажется, что на нем по нынешним временам принижены все разумные пределы. На нем снес по ошибке данные, а тем более таблу и привет, если нет Бэкапа. Апекса нет – это чтобы по быстрому налабать клиента. И т.д. т.п. А Вы говорите, что превышены пределы.
Када-то станки превышали пределы, лишая рабочих работы. Там всякие михайловцы или типа того боролись с ними. Ну теперь другие времена. Да и станки те кажутся допотопными.
12 май 11, 09:08    [10639395]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
vadiminfo
Так тем кто назвал фичи мешают? Тут ждешь каждую новую версию в надежде на новые фичи, а им пределы превышены? Хороши.


А кто говорит что плохи?
Просто их много. ;-)

vadiminfo
Ниче не скажешь. В 8 Оракле превышены? А мне теперь после 11 кажется, что на нем по нынешним временам принижены все разумные пределы. На нем снес по ошибке данные, а тем более таблу и привет, если нет Бэкапа. Апекса нет – это чтобы по быстрому налабать клиента. И т.д. т.п. А Вы говорите, что превышены пределы.


Чем больше фич, тем сложнее "инструмент". ;-)

vadiminfo
Када-то станки превышали пределы, лишая рабочих работы. Там всякие михайловцы или типа того боролись с ними. Ну теперь другие времена. Да и станки те кажутся допотопными.


А зачем бороться?
Сами "умрут". ;-)

Если для нормальной работы нужны "фичи", то либо инструмент подобран не правильно, либо задача решается не правильно.
12 май 11, 12:32    [10640756]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
mad_nazgul
А кто говорит что плохи?
Просто их много. ;-)

А разве их много бывает?

mad_nazgul
Чем больше фич, тем сложнее "инструмент". ;-)

Чем больше фич, тем проще с этим "инструменитом" "инструментировать". Например, снес по ошибке в командировке данные, а у вас есть фича простым запром вернуть обратно.



mad_nazgul
А зачем бороться?
Сами "умрут". ;-)

Тем более.

mad_nazgul
Если для нормальной работы нужны "фичи", то либо инструмент подобран не правильно, либо задача решается не правильно.

"Нормальной работы"? Правильно подобран? Ну так я и говорю что чем больше фич, тем правильнее. Ить фичи могут быть нужны чтобы снизить риски "не нормальной работы" разработчика на всех этапах ЖЦ системы. Любой проект, к, сожелению, имеет разного рода риски. Например, по ходу потребовал заказчик чтобы БД сама оповещала клиента о каких-то критических изменниях данных. Есть фича оповещать клиентов подписавшихся на рассылку событий даже када нет сессии. А нормальная правильная работа клиенту через кажную секунду спрашивать проверять не произошли ли такие изменения?

Если не обращать внимания на проггеров готовых дописывать заплатки вместо фич СУБД, то, скорей всего, "фичи" нужны для "нормального" ЖЦ ИС.
12 май 11, 13:10    [10641040]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
vadiminfo
А разве их много бывает?


Бывает. :-)

vadiminfo
Чем больше фич, тем проще с этим "инструменитом" "инструментировать". Например, снес по ошибке в командировке данные, а у вас есть фича простым запром вернуть обратно.


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

vadiminfo
"Нормальной работы"? Правильно подобран? Ну так я и говорю что чем больше фич, тем правильнее. Ить фичи могут быть нужны чтобы снизить риски "не нормальной работы" разработчика на всех этапах ЖЦ системы. Любой проект, к, сожелению, имеет разного рода риски. Например, по ходу потребовал заказчик чтобы БД сама оповещала клиента о каких-то критических изменниях данных. Есть фича оповещать клиентов подписавшихся на рассылку событий даже када нет сессии. А нормальная правильная работа клиенту через кажную секунду спрашивать проверять не произошли ли такие изменения?


Опять же проблема при проектировании.
Зачем в СУБД пихать мессенджер?!

vadiminfo
Если не обращать внимания на проггеров готовых дописывать заплатки вместо фич СУБД, то, скорей всего, "фичи" нужны для "нормального" ЖЦ ИС.


Зачем?!
Зачем иметь в СУБД мессенджер, когда можно использовать любой внешний?!
Может СУБД еще должна уметь проигрывать AVI файлы?
Тоже фича. Возможно даже кому-то нужная.
12 май 11, 13:25    [10641147]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
miwaonline
Member

Откуда:
Сообщений: 2249
Хм, а топик мне начинает нравиться - народ всерьез обсуждает возможность запуска оракла для обработки тысячи записей в месяц, поскольку у постгреса через пару лет будут проблемы с производительностью.

Продолжайте, господа, не останавливайтесь ©
12 май 11, 13:49    [10641347]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
mad_nazgul
Бывает. :-)

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


mad_nazgul

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

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

mad_nazgul
И вообще "универсал, это тот кто делает все одинаково плохо" :-)
Поэтому я очень "настороженно" отношусь к добавлению фич.
Если фича нужна, то это скорее всего проблема в проектировании, либо в инструменте.


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

У Оракла, по крайней мере, проблем в инструменте по сравнению с другими СУБД вроде особо не обнаруживается.
А проблемы в проектировании могут оказаться у любого. Такие риски исключать было бы чрезмерно самонадеяно. А ЖЦ в общем случае может иметь модели не предполагающие на этапе выбора СУБД предвить все.



mad_nazgul

Опять же проблема при проектировании.
Зачем в СУБД пихать мессенджер?!



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

mad_nazgul

Зачем?!
Зачем иметь в СУБД мессенджер, когда можно использовать любой внешний?!
Может СУБД еще должна уметь проигрывать AVI файлы?
Тоже фича. Возможно даже кому-то нужная.


Это какой внешний? Как он узнает, что в ней что-то произошло? Запрос пошлет? Кажную секунду? Написаный проггерами или мессажер ОСи приспособить? Так оси разные могут быть. И прог много может быть.
Если СУБД файл-серверная, то типа и проигрывает. А клиентсевреная может тока запросы возвращать, которые юзеру клиент представляет. В том числе и фильмы. А так да у Оракла есть поддержка и мультимедиа.
12 май 11, 14:20    [10641601]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
miwaonline
Хм, а топик мне начинает нравиться - народ всерьез обсуждает возможность запуска оракла для обработки тысячи записей в месяц, поскольку у постгреса через пару лет будут проблемы с производительностью.
Продолжайте, господа, не останавливайтесь ©


Насчет PostgreSQL ничего не скажу, но наши программисты умудрились тормознуть MS SQL на ~4000 - 5000 записей (одна табличка)
Запрос на 8-ядерном ксеоне выполнялся до 15 минут.
Так что... <:o)
12 май 11, 15:27    [10642267]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить