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

Откуда: Новосибирск
Сообщений: 1112
Перечитал весь форму, но конкретики так и не нашел (возможно плохо искал).
Наберусь смелости спрошу еще раз (не быть, не посылать, камнями не кидать.. плиз).
Вопрос о создании бухгалтерской учетной системы (склад, торговля, заказы, розница).
На рознице следует сделать акцент т.к. приутствует момент загрузки данных о дневных продажах с магазинов. Магазинов может быть до 50-100, номенклатура в них до 5000. Реальнов базу грузиться до 50000 строк о дневных продажах + строки обычных складских документов порядка 12000 в день + 100-200 строк других документов. В таблицах строк информацая компактная (идентификаторы товаров, складов, партнеров и т.д.+количество, цена, сумма и т.д.). Справочники в целом около 50000-60000 записей, уже более насыщенные (наименования, полные наименования, соды, адреса и т.д. вобщем достаточно длинные строки). Пользователей 40-60. Сервак может быть и однопроцессорный с наворотами и двух-процессорный, т.е. тут особой экономии не намечается. Отчетеов достаточно много, есть сложные для маркетологов с навороченными подзапросами и т.д.
На сегодняшний день система реализована под MS SQL Server 2000. Годовой размер БД 10Гб. База не должна сворачиваться в течении года, но в конце года можно и свернуть.
Вопрос - на сколько реально реализовать то же под FireBird ? Затраты по переделке не рассматриваются - это не проблема. Речь идет о создании серийной системы, поэтому хотелось бы использовать бесплатную СУБД. Не будет ли это сыром в мышеловке ?
24 сен 05, 12:52    [1907280]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
VladSh
Member

Откуда:
Сообщений: 244
Можно конечно. Судя по объемам - проблем не должно быть.
Но надо учитывать, что по идеологии FireBird (версионник) очень здорово отличается от MS SQL (блокировочник).
Чтобы сделать оптимальную по быстродействию СУБД, взгляд разработчиков должен быть повернут ортогонально.

--
Шумов В.
www.acdplus.ru
24 сен 05, 22:38    [1907524]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
DrKonito
Member

Откуда:
Сообщений: 88
Даже если особых технологических проблем не будет, рано или поздно придет начальство, которое скажет: ОК, а теперь все то же самое сделайте под Нормальной БД (Оракыл, MC или ДБ/2) :)
Кредит доверия к Файрберду низок и не важно связано это с объективными технологическими причинами или плохим маркетингом. Так что писать чисто под файрбёрд - , извиняюсь, как справлять естественную надобность против ветра.

Как вариант, можете сделать ваше приложение БД - независимым хотя это стоит денег, конечно.
25 сен 05, 23:04    [1908155]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
Павел Ишенин
Member

Откуда: Красноярск
Сообщений: 361
автор
Даже если особых технологических проблем не будет, рано или поздно придет начальство, которое скажет: ОК, а теперь все то же самое сделайте под Нормальной БД (Оракыл, MC или ДБ/2) :)


Кстати, под Oracle обычно не сильно сложно передвинуть то, что сделано на Fb.
26 сен 05, 04:58    [1908327]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
Мимопроходящий
Member

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

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

olegov
...
o> На сегодняшний день система реализована под MS SQL Server 2000. Годовой размер БД 10Гб.
o> База не должна сворачиваться в течении года, но в конце года можно и свернуть.
o> Вопрос - на сколько реально реализовать то же под FireBird ?
Забудь.
На FB такие задачи требуют прямых рук и соответственную квалификацию.
MS SQL в этом отношении более лоялен.

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

Posted via ActualForum NNTP Server 1.3

26 сен 05, 10:59    [1908874]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
olegov
Member

Откуда: Новосибирск
Сообщений: 1112
Мимопроходящий

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

Забудь.
На FB такие задачи требуют прямых рук и соответственную квалификацию.
MS SQL в этом отношении более лоялен.

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

Posted via ActualForum NNTP Server 1.3


Вопрос общий. Проблема рук решается нанятием таких рук на работу. Интересует потенциальная возможность. Почему-то грызут сомнения.... Но одни "руки" говорят "легко", другие "Абсурд". Сам FireBird потыкал - технология понравилась. Многое что в MS SQL делается через ж... здесь в два прихлопа, правда есть и обратные ситуации, но их меньше. Поэтому вопрос только в возможности FireBird. Можно рассматривать даже 2.0, т.к. проект "длинный" - год-полтора. Надеюсь 2.0 к тому времени будет или ?....
26 сен 05, 21:49    [1911728]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
olegov
Member

Откуда: Новосибирск
Сообщений: 1112
DrKonito
Даже если особых технологических проблем не будет, рано или поздно придет начальство, которое скажет: ОК, а теперь все то же самое сделайте под Нормальной БД (Оракыл, MC или ДБ/2) :)
Кредит доверия к Файрберду низок и не важно связано это с объективными технологическими причинами или плохим маркетингом. Так что писать чисто под файрбёрд - , извиняюсь, как справлять естественную надобность против ветра.

Как вариант, можете сделать ваше приложение БД - независимым хотя это стоит денег, конечно.


Оно - Руководство заказчика и сказало "Ок". а теперь все то же но под FB. Решили легализоваться. В центральном офисе согласны купить MS SQL, но в региональные отделения зажали.
26 сен 05, 21:51    [1911734]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
olegov
Member

Откуда: Новосибирск
Сообщений: 1112
Павел Ишенин

Кстати, под Oracle обычно не сильно сложно передвинуть то, что сделано на Fb.

Мы эту возможность то же рассматриваем. А статеек на этту тему никто не встречал ?
Вообще прикалывает такая вещь http://www.is-pro.ru/ru/about/index.html
26 сен 05, 21:55    [1911743]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
Павел Ишенин
Member

Откуда: Красноярск
Сообщений: 361
Если тебя прикалывает строчка
статья

Используемые СУБД: Pervasive, Oracle, MS SQL или FireBird


то скажу, что у нас есть системы которые работают на ms sql, oracle, fb
причем для работы с oracle и fb используется одно и тоже приложение (в смысле exe). Запросы один в один, только в oracle к названиям таблиц схему приписывать надо.
27 сен 05, 05:23    [1911989]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
ЛП
Guest
olegov
В центральном офисе согласны купить MS SQL, но в региональные отделения зажали.

А что, в региональных отделениях - тоже 40-60 одновременно работающих юзверей и 10Гб в год? Если в регионах маштабы мельче - то чем MSDE не устраивает?
27 сен 05, 05:44    [1911997]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
2Павел Ишенин
А зачем вам тогда навороченный сервер, если его фишками воспользоваться нереально? Код запрос ведь один в один.
27 сен 05, 10:13    [1912430]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
Кувалдин Роман
Member

Откуда: Московская область
Сообщений: 1296
А в сторону MySQL или PostgreSQL смотреть не пробовали?
27 сен 05, 10:19    [1912467]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
wellx
Member

Откуда:
Сообщений: 70
olegov
DrKonito
Даже если особых технологических проблем не будет, рано или поздно придет начальство, которое скажет: ОК, а теперь все то же самое сделайте под Нормальной БД (Оракыл, MC или ДБ/2) :)
Кредит доверия к Файрберду низок и не важно связано это с объективными технологическими причинами или плохим маркетингом. Так что писать чисто под файрбёрд - , извиняюсь, как справлять естественную надобность против ветра.

Как вариант, можете сделать ваше приложение БД - независимым хотя это стоит денег, конечно.


Оно - Руководство заказчика и сказало "Ок". а теперь все то же но под FB. Решили легализоваться. В центральном офисе согласны купить MS SQL, но в региональные отделения зажали.


Тогда смотрите на связку Oracle+Fb or sybaseASE 15 + Fb.
Преимущества перед MS SQL работает на линухе, т.е. выйдет дешевле чем лицензироваться под MS SQL. Oracle SE One - 149$/user. ASE ~= Oracle по цене, но проще портировать под сайбейз с MSSQL. FB легко потянет регионы и немаловажно , что можно получить оперативную и качественную помощь от разработчиков файерберда на русском. ни одна другая база этого не позволяет.
27 сен 05, 12:47    [1913443]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
wellx
Member

Откуда:
Сообщений: 70
wellx
olegov
DrKonito
Даже если особых технологических проблем не будет, рано или поздно придет начальство, которое скажет: ОК, а теперь все то же самое сделайте под Нормальной БД (Оракыл, MC или ДБ/2) :)
Кредит доверия к Файрберду низок и не важно связано это с объективными технологическими причинами или плохим маркетингом. Так что писать чисто под файрбёрд - , извиняюсь, как справлять естественную надобность против ветра.

Как вариант, можете сделать ваше приложение БД - независимым хотя это стоит денег, конечно.


Оно - Руководство заказчика и сказало "Ок". а теперь все то же но под FB. Решили легализоваться. В центральном офисе согласны купить MS SQL, но в региональные отделения зажали.


Тогда смотрите на связку Oracle+Fb or sybaseASE 15 + Fb.
Преимущества перед MS SQL работает на линухе, т.е. выйдет дешевле чем лицензироваться под MS SQL. Oracle SE One - 149$/user. ASE ~= Oracle по цене, но проще портировать под сайбейз с MSSQL. FB легко потянет регионы и немаловажно , что можно получить оперативную и качественную помощь от разработчиков файерберда на русском. ни одна другая база этого не позволяет.


И еще могу добавить - если решите брать Оракл , то в качестве локальных баз посмотрите на Fyracle (Oracle mode fo Firebird) www.fyracle.org http://www.janus-software.com/ Тогда даже синтаксис запросов менять не надо. Да и девелоперская версия стоит около 50-100 баксов . Причем в смысле парсинга PL/SQL сабж много впереди EntrepriseDb будет , да и дешевле во много раз.
27 сен 05, 13:12    [1913643]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
olegov
Member

Откуда: Новосибирск
Сообщений: 1112
ЛП
olegov
В центральном офисе согласны купить MS SQL, но в региональные отделения зажали.

А что, в региональных отделениях - тоже 40-60 одновременно работающих юзверей и 10Гб в год? Если в регионах маштабы мельче - то чем MSDE не устраивает?


В региональных та же фигня.
27 сен 05, 13:38    [1913826]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
olegov
Member

Откуда: Новосибирск
Сообщений: 1112
А про FB2.0 ченить слышно ? Когда ожидается ? Чего будет ?
28 сен 05, 00:08    [1916171]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
hvlad
Guest
olegov
А про FB2.0 ченить слышно ? Когда ожидается ? Чего будет ?
Вопрос задан не в тот форум.
Ожидается в этом году.
Чего будет - можно почитать в Release Notes или пощупать 3-ю альфу (1-я бета уже скоро)
28 сен 05, 01:02    [1916261]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
Константин Заровный
Member

Откуда: Волгодонск
Сообщений: 954
olegov

Вопрос - на сколько реально реализовать то же под FireBird ? Затраты по переделке не рассматриваются - это не проблема. Речь идет о создании серийной системы, поэтому хотелось бы использовать бесплатную СУБД. Не будет ли это сыром в мышеловке ?


Согласно моему опыту работы с IB, сделать можо, но:

1. Те запросы, что MSSQL сам глотает и отрабатывает в нормальные сроки - IB может обрабатывать годами. (Хотя при подходе доработать напильником, от IB можно добиться результатов не сильно уступающих MSSQL).

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

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

Итого: Поддержка халявного IB - это своеобразного рода трюк с заманиванием покупателя на халяву. Для небольшой конторы вполне нормально будет работать конторам побольше - пусть платят дважды. За "бесплатный" IB + За переход + за Oracle.

За соответствующую оплату могу даже решить технические вопросы (если делать будете на Delphi)
28 сен 05, 02:22    [1916290]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
Павел Ишенин
Member

Откуда: Красноярск
Сообщений: 361
AAron

А зачем вам тогда навороченный сервер, если его фишками воспользоваться нереально? Код запрос ведь один в один.


А что все фишки Oracle лежат только в области SQL запросов?

Я конечно написал про запросы один в один.
1. Это относится только к DML запросам.
2. Часть DML запросов всеже отличается
3. Некоторые фишки Oracle, типа хинты можно вставлять в запрос и это не окажет никакого влияния на Fb.
28 сен 05, 05:32    [1916349]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Вот именно, фишки лежат не только в области SQL/DML, но и в других "частях" Оракла или SQL Server'a.

Поэтому я и считаю, что неразумно писать приложение, с одним и тем же DATA LAYER для разных серверов, лишая приложение возможности работать со всем доступным функционалом.
28 сен 05, 10:51    [1917010]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
mod
Member

Откуда:
Сообщений: 2318
Кувалдин Роман
А в сторону MySQL или PostgreSQL смотреть не пробовали?

и не смотрите: первая слишком урезана от SQL, вторая глючная...
28 сен 05, 15:25    [1918835]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 600

AAron

Поэтому я и считаю, что неразумно писать приложение, с одним и тем же DATA LAYER для разных серверов, лишая приложение возможности работать со всем доступным функционалом.


С какой это радости приложение должно лишаться этой возможности?

Posted via ActualForum NNTP Server 1.3

28 сен 05, 15:28    [1918848]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
mod
Member

Откуда:
Сообщений: 2318
Как показывает практика такие обсуждение в итоге сводятс к тому что круче Оракл и МС СКУЛЬ. Ориентируетесь следуюшим образом: под Windows Oracle на всю мощь всё одно не развернуть из-за ограниченности Винды... В месте с тем по возможностям он беспорно круче. Однако на Ms SQL Вы свою базу сварганите значительно быстрее. и поддерживать её проще будет бо там до кучи всё более автоматизировано...
28 сен 05, 15:32    [1918868]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Спорно на счет Oracle на винде. Вполне себе номано крутится.
Как и предыдущее высказывание про постгресс
28 сен 05, 16:34    [1919289]     Ответить | Цитировать Сообщить модератору
 Re: Опять про выбор СУБД  [new]
Gluk (Kazan)
Member

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