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