Ув. Господа.
Сравнение СУБД невозможно без наличия исходных входящих параметров.
Я около 2-х лет назад столкнулся с проблемой выбора СУБД для дальнейшего
использования в торгово-производственной компании.
Список:
1) Стоимость внедрения до 50 000 - 70 000 убитых енотов. (в жывых деньгах) :)
2) Кол-во итерраций по товару в одной таблице (сейчас) 16 млн. записей в год т.е. свободные таблицы на VFP (сейчас) дробятся на тучу маленьких медвежат.
3) Кол-во пользователей 100 - офис, 120 - производство, 150 - розница т.е. скорость обработки информации оставляет желать лучшего.
4) Удаленное разнесение клиентов по всем регионам РФ и странам СНГ.

ИЗ ВСЕГО КОМПЛЕКСА СУБД - рассматривал:
1) Oracle - дорого!!!!!
2) MS - тоже...........
3) .......
Есть ли у кого опыт разработки и внедрения продукта на СУБД без лицензий и прочего отбирания денег, или хотябы за разумную стоимость но один раз и на все случаи жизни, тоесть без ограничений по пользователям, кол-ву процессоров...

Буду очень признателен ВСЕМ кто заинтересуется моим вопросом.

Хотелось бы еще отметить, что эта система могла быть портированна на NIX платформу как сервер так и клиент.
Но таких разработок я не видел (хотя может плохо ищу)

GoldА клиента на джаве - очень мощная штука!

Никогда не сталкивался с джавой (кинте хорошую ссылку почитаю...)

GoldPostgres.
Я б тебе FireBird посоветовал, но там прийдётся репликацию руками делать до выхода след. версии :-/

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

Я слышал есть такая СУБД - называется LINTER чем-то напоминает Oracle но только
полегче без супер наворотов может кто работает на ней .... отзовитесь.

Gold Может у тебя в табличке просто 100 миллионов строк, состоящих из одного строкового поля :-), а может быть 100 миллионов строк сто 100 всевозможными полями, по которым потом надо будет считать суммы, группировку делать, сортировать и т.п.
У меня 100 миллионов записей небыло никогда, но я думаю что на мощном железе при правильном проектировании и настройках нормалоно бы обрабатывалось. Для меня вот щас страшным словом кажется миллиард записей

Общий объем данных по товару гдето 150-160 гигов (но это в свободных таблицах).
Так что тут и считать то нечего, сразу все видно.

michael_
Вы оптимист, однако.

А насчет выбора - я бы бесплатный сыр не кушал, он только в мышеловке бывает. Купите ORACLE, Sybase ASE или DB2 - объемы и требования у Вас очень серьезные. Не надо на СУБД экономить. Потом голову снимут, а она одна. Пусть производитель СУБД тоже ответственность разделит.
Насчет цены - поговорите с продавцами, может чего и скинут.

Дык я бы взял да денег не дают, а производительность требуют вот и болтаюсь как ...

Я вот сейчас запал на FreeBSD - хорошая ОС вот и ищу под неё СУБД которая будет
удовлетворять моим требованиям.

GoldВобще-то тут конечно трёхзвенка напрашивается... -/

А что это такое и с чем его едят...

GoldА чем тебя постгрес не устраивает? Конкретно чем? Перечисли...

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

Yo !!! Выразил мои внутренние терзания хотел я когдато поставить кластер на редхатах.

Вот если постгресс поддерживает кластерную работу то я начну копать в
этом огороде.

И еще если говорите что постгресс рулеззз и куллл то фирмы крупные на нем должны работать, а я в своём Мухосранске таких не знаю.

Рыжий КотОпять титаники строим? ню-ню...



Ну да ....
Хотя если бы не этот ..... айсберг.

Romale TAG~s... а я в своём Мухосранске таких не знаю.

Так может тогда и СУБД нужно выбирать исходя не из цена/производительность, а из того, какую в Вашем окружении могут поддержать (объяснить)?

Да поддержать то могут любую просто я не видел крупных фирм которые на постгрессе работают, если есть ссылочка то пожалуста сбросьте.

LSVВыбирать стоит только из Oracle и MSSQL ИМХО...
При таких объёмах пользы от других систем будет недостаточно...
Не выбирайте также и экзотику : запаритесь обслуживать и бороться с проблемами в условиях отсутствия информации и кадров.

Непонятно, почему при таком масштабе нет денег на приличную СУБД... :(

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

Скачал я ЛИНТЕР, установил на ХР, поставил среду разработки .
Прикольная СУБД, интересно как наши такую смогли сделать.
Если кто работал на ней раскажите что за зверь, потому что по первому впечетлению система быстро обрабатывает записи и делает выборки.
По крайней мере не уступает ФОКСПРО, а данных может держать поболее.

<<<Было недавно тут про Линтер.
http://www.sql.ru/forum/actualthread.aspx?tid=68376
на меня впечатление не произвело.>>>

До мелкомягких ей конечно ещё расти и расти но это единственная СУБД из русских, которая сертифицированна по 2-му классу защиты (если не ошибаюсь)
и используется в МВД, ФСБ, минобороны РФ.

Вот только производственных примеров не видел -- плохо :(

onstat-
Дабы не развивать лишную полемику,
какой бюджет проекта?
Может денег хватит только на CD-R + матрицы?
Тогда оставайтесь с медвежатами.

С уважением

Бютжет проекта 50 - 70 тыс. убитых хомячков
Плюс к этому 5 программистов на окладе.
Это вместе с постановщиком задач он-же руководитель проекта.

По всем вопросам сразу и попорядку:
onstat-Исходя из обьемов базы в 150 Гб вы вложетесь только в нормальное
(не брендовое) железо + UPS + систему для разработчиков.
Я не говорю уже о покупке операционнки и базы данных.
Вы уверенны, что вы будете регулярно использовать все
150 Гб базы, и они не будут лежать мертвым грузом на дисках.
Есть ли требование к гарантированному времени отклика системы
для конкретных операций?

Может всетаки CD-R и матрицы?
Слишком уж большие требования для таких денег.

Все накопленные данные необходимы для ежедневного использования так как
в процессе работы оптовые покупатели и структурные подразделения производят движение с товаром произведенным или проданным ещё в 1996 - 1998 году.
Товар не имеет срока годности и имеет спцифику продаваться очень долго.
Поэтому если CD-R то с ченджером на ... дисков.http://www.sql.ru/forum/images/happy.gif

Дедушка Мазай...и лет 10 на разработку и внедрение.

За 1-год была подготовленна полная структура и описание на необходимую реализацию.

Опыт работы данного коллектива позволяет готовить правильно работающие приложения в максимально короткие сроки. Хотя большая часть специалистов и
работала последнее время только на Фокспро но есть спецы, которые в совершенстве владеют С++.

michael_Возьми взрослую СУБД (например, Sybase ASE :) ), но developer edition, или как она там у выбранной платфотмы называется, то есть даром. И начни разработку.

А там или ишак или падишах сдохнет, пока вы свой титаник построите.

Разговор о лицензиях отодвигается на год-два в лучшем случае.

С большим удовольствием но готовый продукт требуют к следующему новому году...

ASCRUSМне вот интересно - почему при выборе СУБД не сильно учитывают стоимость ее сопровождения и разработке на ней проекта, а только стоимость ее начальной покупки, которая мизер по сравнению с ними. Неужели Вы действительно думаете, что достаточно купить/взять даром даже промышленную Enterprise СУБД и на такой по обьему и сложности все само собой побежит/полетит ?

Причем Вы пишите:
авторБютжет проекта 50 - 70 тыс. убитых хомячков
Плюс к этому 5 программистов на окладе.
Это вместе с постановщиком задач он-же руководитель проекта.
А что, эти 5 программистов настолько сильны, что им достаточно дать любую СУБД и они спроектируют на ней нормальную оптимизированную под такие обьемы БД ? Думаю что нет. Значит после выбора "дешевой" СУБД Вам придеться еще и проектировщика БД искать. Причем чем ниже будет ценовая категория СУБД, тем меньше будет опыт работы с большими обьемами данных у соотвествующего специалиста. А если Вы еще начнете искать "дешевого" специалиста, то вообще непонятно тогда, что можно обсуждать. Так что при таком бюджете я наверное бы сделал 4 вещи:
1. Написал концепцию перевода и развития проекта с описанием требуемой функциональности
2. Нашел бы готовое решение, пусть и только с базисом, но возможностью его расширения в нужную сторону. Составил по нему коммерческую составляющую его стоимости, стоимости доработки до нужного функционального уровня и стоимости его запуска.
3. Составил концепцию разработки собственного проекта, разложил его на коммерческую составляющую, написал записку-обоснование выбора средств разработки, этапы разработки с их продолжительностью, штатное расписание специалистов и все планируемые и непланируемые затраты.
4. Подумал о переносе аналитики на OLAP/DSS сервер, оставив работающим OLTP как есть. Соотвествующе так же написал бы коммерческую составляющую на стоимость закупки, запуска и сопровождения такого сервера и записку обоснования выбора СУБД.
Ну а дальше пусть начальство само думает и выбирает с предложенных вариантов, это уже их проблемы. Если они чего нибудь вякнут по поводу что все дорого, значит им проект этот не заказан и можно смело снимать с себя по нему обязательства.

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

Структура и полное описание уже готово - основная загвоздка с выбором СУБД
а там под определенные специфики оной нужна будет небольшая доработка.

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

Другой вопрос, что нужно будет подготовить сисадмина.

onstat-
Исходя из обьемов базы в 150 Гб вы вложетесь только в нормальное
(не брендовое) железо + UPS + систему для разработчиков.
Я не говорю уже о покупке операционнки и базы данных.


Железо уже имеется 3 двух процессорных сервера с RAID массивами по 150 ГБ.
и остальные приблуды типа UPS и такдалее.

Да ещё, можно попробовать создать распределенную модель.

Первичные данные вводятся и редактируются в реальном режиме времени на базе с максимальной по быстродействию СУБД (например mySQL) - объём хранимой информации оставляет максимально по наибольшей таблице максимум 45 тыс. записей в день. Так-же интернет ориентированная СУБД будет плюсом при организации работы удаленных подразделений (Всего 100-120 USER-ов).

Промежуточные данные хранить на СУБД позволяющей стабильно работать с
объемом информации по таблице максимум в 3-3,5 млн. записей в месяц - полтора (PostgressSQL) и 150-200 USER-ов.

Архивные данные хранить в OLAP.

P.S. Но затраты еще не считал

Ваше мнение.

gzК какому Новому году ?

к 1.01.2006

q32768
Если есть возможность распределенки как территориально, так и функционально, то вполне приемлемо решение на PostgreSQL. Реплицируешь данные, аггрегируешь как надо, распределяешь нагрузку пользователей, каую хочешь трехзвенку строй... В общем, однозначно рулит!
Я тут неделю целую в тестовом режиме травлю PostgreSQL большой транзакционной нагрузкой. Пока пациент сорее жив, чем мертв. :)

А максимально возможный объем записей и пользователей Вы не проверяли для
PostgreSQL ?
Из моего опыта : FoxPro сервер 2*2,4 Xeon RAID 6*100Gb 30 активно работающих
пользователей(бьют и редактируют инфу) 45 время от времени(задающих различной нагрузки отчетные запросы) 5 GigabitInternet карт на сервере Маршрутизатор и комутатторы гигабитный и стомегабитные соответственно.

При наличии в таблице 3 000 000 записей и размере таблицы 0,6 Гб все работает
нормально, при 5 000 000 записей и соответственно 1,0 Гб замедление в обработке
запросов на добавление, удаление, редактирование на 150-250%, а бывает и хуже.

gzЗа год "с хвостиком для 5 программистов эта задача решаемая.

michael_ Gold я думаю что на мощном железе при правильном проектировании и настройках нормалоно бы обрабатывалось. Для меня вот щас страшным словом кажется миллиард записей

Вы оптимист, однако.

А насчет выбора - я бы бесплатный сыр не кушал, он только в мышеловке бывает. Купите ORACLE, Sybase ASE или DB2 - объемы и требования у Вас очень серьезные. Не надо на СУБД экономить. Потом голову снимут, а она одна. Пусть производитель СУБД тоже ответственность разделит.
Насчет цены - поговорите с продавцами, может чего и скинут.

На СУБД для такой задачи экномить нельзя. Вполне согласен с предыдущим "оратором". Он же и приложил их список

Экономить нельзя, но выживать както нужно?

Тут ко мне недавно Navision подкатывали, рассчитали проект для офиса и
магазинов - получилось на 1-й год 254 000 евро.(офис) на 2-й и 3-й год 486 000 евро(магазины) так меня послали за такие суммы, досихпор иду....

gz"Тут ко мне недавно Navision подкатывали, рассчитали проект для офиса и
магазинов - получилось на 1-й год 254 000 евро.(офис) на 2-й и 3-й год 486 000 евро(магазины) так меня послали за такие суммы, досихпор иду...."

Не надо путать стоимость СУБД и стоимость разработки проекта (если я правильно понял). Эти цифры должны Вам и Вашим работодателям показать реальную стоимость проекта, хотя, наверняка, завышенную.
Поэтому, для Вас, мне кажется важно не "вляпаться" и не взять на себя много.
А это сплошь и рядом. Берутся, например, писать проект люди, на ORACLE никогда не работавшие. Затем объясняют, что долгие запросы объясняются "крутостью" Oracle. Через месяц выясняется, что этот человек не имел понятия, что можно применить индексы.
К сожалению, в "нашей области" очень много как "шапкозакидательства" со стороны разработчиков, так и "абсолютного непонимания" проблем со стороны заказчика. Выясняется, опять к сожалению, это с запозданием, когда летят сроки и система не соответствует требованиям.
Резюме. Хорошо подумайте, прежде чем взяться за проект. И не экономьте на инструментарии, поскольку это не "месячный" проект и должен работать, наверняка, не один год. Если "начальство" этого не понимает сейчас, то поймет впоследствии. Примеров тому множество.

дык я о чём и говорю, что хотят всю стоимость проекта свести к 50 000 енотов,
не считая зарплату.