Ищу коллег для разработки СУБД

Как полагается с блекджеком и шлюхами?

А смысл? Написать забавы ради еще один велосипед? Или есть какие-то революционные идеи? Если есть, то почему их нельзя реализовать в существующих СУБД?

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

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

Скажем так, вопрос этот скорее только к тем кто хоть раз в жизни написал хоть один запрос на 50+ строк и хоть одну хранимую процедуру больше чем на 100 строк.

> Потому что нельзя в существующие субд вставлять блекджек и шлюх, кроме разве что оракла.

Жаниццо тебе надо барин.

p.s. почему бы не прикрутить соответствующих шлюх к, например, Postgres?

Есть некоторые случаи когда проще написать с нуля чем переписывать.
Потому основной разработчик от них и ушёл и основал vertica.

Опять же, тот же разраб сказал что не должно быть двух языков в одном проекте, то есть (например) sql в базе, perl в логике. потому что получается какая-то фигня. то ли всю логику вносить в базу то ли всю выносить, забив на триггеры и прочее.

Как пример, нужно выбрать все накладные с ПРИБЫЛЬНОСТЬ() которых больше 10000руб. если там начинаются завязки на тарифы и скидки клиентов то получается что либо все эти функции должны быть ВНУТРИ базы и от perl нужно отказаться либо всё должно быть на перле и из базы будет делаться просто select * from mytable без where, особенно если говорить о генерации кода автоматически (курим BPL и прочее), такое я тоже в жизни уже видел в куче enterprise java-проектов.

В общем, если есть желание и время - присоединяемся, если хочется потроллить - проходим мимо.

Делай это но с джойнами и check constraints http://www.slideshare.net/mattetti/couchdb-perform-like-a-pr0n-star

Расскажу тебе историю.

Собеседовали мы пых-кодера, у которого в ЗУН значился оракел и PL/SQL. Ему, как и всем тестовое задание: есть пользователи, они входят в какие-то группы и между пользователями есть отношение субординации. Вот типа надо спроектировать БД и простейший web-интерфейс наваять к этому делу.

Через 2 дня присылает решение. Есть таблица groups с единственным полем NAME и есть таблица users, где указано имя пользователя, и, через запятую, список групп, в которые он входит(строкой). Я спрашиваю: ну а что будет, если мы сменим имя у группы. Ответ: напишу триггер, который при изменении данных в таблице groups проапдейтит таблицу users. (субординацию он замутил таким же макаром)

Я и раньше питал недоверие к хранению бизнес-логики в БД. А тут уж совсем усомнился в нужности триггеров при грамотном проектировании БД.

p.s. удачи тебе в этом нелёгком деле.

>После чего понял что дальше наращивать функционал смысла нет и нужно писать начисто на C/C++.

О как, таки догадался.. А чем PostgreSQL не устроил?.. Под него бы ещё кластеризацию приемлемую..

Где можно с концепциями ознакомиться?

просто у тебя не было ни одного сложного проекта. ))))))

по поводу кодера - конечно грустно.

У меня есть вот щас например проект автоматизации управляющей компании, и я мега-рад что у меня ВСЁ от начала до конца внутри оракла.

> просто у тебя не было ни одного сложного проекта. ))))))

Не буду троллить и доставать пиписку для проведения метрологических процедур.

Раз ты решил, что оно тебе надо - удачи.

Не особо разбираюсь в тонкостях БД, но всё равно спрошу, уверен ли автор, что не существует проекта, к которому можно присоединится ? Или хотя бы форкнуть ?

В любом случае пожелаю успеха, т.к. дело нелёгкое

разговаривал с mysql-хакером из mail.ru (ну и основным поставщиком патчей в nginx), пришли к выводу что примкнуть не к кому. проще писать с нуля.

> На данный момент написал proff of concept на перле, успешно выполняющий запрос селект =)

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

Выжимки из коцепта:

Хочется сделать большой упор на кластеризацию (в том числе и распределённую, когда один сервер в германии, другой в россии).

даже в оракле кластеризация это отдельная песня. хочется сделать чтобы всё было прозрачно, чтобы было три типа "серверов" - хранилище, "исполнитель", "хранилище+исполнитель", ну и соответственно чтобы тейблспейсы можно было в (может даже в горячую) пилить на части между серверами, или наоборот, делать резервную копию.

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


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

блин, сам знаешь, у меня таких знаний нет, чтобы к разработке твоей СУРБД присоединиться)буду просто болеть в сторонке)и да, на релиз пригласи)))

Да, насчёт лицензии -- VPL(Vahvarh Public License) пойдёт?

>А вообще есть желание сделать чтобы она слушала на 80 порту, ибо в том же оракле есть и xml и xslt и листенер так конфигурится, просто мало кто про это знает.

В курсе..

>Как пример - задача, есть некая БД (достаточно большая в сумме), слишком сильно нагруженная запросами к нескольким таблицам. хочется их вынести в отдельный тейблспейс и отзеркалировать его на одну-две машины, чтобы запросы пустить туда.

Задумка хорошая. Надеюсь, ты понимаешь, что тут придётся свою файловую систему разрабатывать, помимо всего прочего.

ну не файловую но систему распределённого хранения данных по некоему rowid. желательно ещё и с софтварным распределённым raid.

Фактически это и выльется в кластерную распределённую сетевую файловую систему в рамках определённой СУБД..

я бы просто не называл это _файловой_ системой. потому что под файлом обычно подразумевается нечто совсем другое нежели под строкой в базе.

Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали СУБД суть такова... Пользователь может установить СУБД на Linux. И если пользователь имеет кластер, то есть кластерная ФС в коробке. Можно грабить корованы...

в лужу пёрнул? возьми с полки горохового супу.

уважаемый хранить всю логику в БД - дурной тон. Насчет тормозов - измени лучше структуру БД - будет больше толку. Очередной велосипед никому не нужен. А так городить очередной велосипед на дурно спроектированной БД - оно не кому не нужно.

>>>Опять же, тот же разраб сказал что не должно быть двух языков в одном проекте, то есть (например) sql в базе, perl в логике. потому что получается какая-то фигня. то ли всю логику вносить в базу то ли всю выносить, забив на триггеры и прочее.

Зачем ? Сделай на plsql то что проще там - остальное ( что там у тебя ?) - на perle.

>>> просто у тебя не было ни одного сложного проекта. ))))))

Отвечу на это так: Никому не нужен результат с большим количеством данных. Соотв запрос с результат 4 миллиона строк теряет смысл. Где ты еще видел тормоза ?

> Никому не нужен результат с большим количеством данных. Соотв запрос с результат 4 миллиона строк теряет смысл.

промежуточные результаты не рассматриваем? а уж как неэффективно умеют пользователи писать запросы - так это отдельная история

> потому что под файлом обычно подразумевается нечто совсем другое нежели под строкой в базе.

эффективнее данные хранить по столбцам - в большинстве случаев меньше данных надо поднимать при отработке запроса

>>>промежуточные результаты не рассматриваем? а уж как неэффективно умеют пользователи писать запросы - так это отдельная история

Это проблема структуры БД + неправильных запросов ( сам же и сказал ). ПОхоже людям вместо того что оптимизировать свою БД проще написать еще один велосипед. Ну в добрый путь.

так где ты собственно предлагаешь хранить функцию ПРИБЫЛЬНОСТЬ()?

Если в БД это тогда как раз и будет "ЛОГИКА В БД", а если в перле, то это будет "выбрать 4млн строк чтобы из них потом выбрать только 10 строк"

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

> Если в БД это тогда как раз и будет "ЛОГИКА В БД", а если в перле, то это будет "выбрать 4млн строк чтобы из них потом выбрать только 10 строк"

Зарекся троллить в этой теме, но видимо, придётся.

Мне казалось, что решение писать "свою" СУБД продиктовано некими объективными причинами. После этого заявления мне начинает казаться, что всётаки у тебя есть некоторые пробелы как по части составления запросов, так и по части проектирования БД. Которые ты компенсируешь дополнительными фичами оракла. Не в таком, конечно объёме как собеседуемый в моём рассказе, но в том же ключе "запихаем всё в одну большую таблицу, и будем в ней хранимыми процедурами рулить" как это делают в Excel'e с помощью вижуалвасика.

Зачем нужно выбирать 4 млн строк? Почему бы не отсечь условиями 3 999 990 записей?

> так где ты собственно предлагаешь хранить функцию ПРИБЫЛЬНОСТЬ()?

KISS.

> или ты предлагаешь

На MySQL работает Википедия, на MSSQL 1С. А что из себя представляют ваши "крупные проекты"? Вы вообще кто, что бы свое мнение иметь? Может ваши проекты оттого такими разжиревшими и получаются, что все время уходит за заморочки типа "бороду сверху оделяла ложить или под низ"?

С таким подходом с вами никто не будет сотрудничать. Так же совершенно не озвучен PROFIT с сего дела. Иль вы со студентиками и школотой решили сотрудничать?

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

Также приведите список ссылок, где вы выступили со своим предложением. Будет очень печально, если все ограничивается толксами лора.

Сейчас вы недалеко ушли от парнишки с караванами.

>так где ты собственно предлагаешь хранить функцию ПРИБЫЛЬНОСТЬ()?

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

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

Те, кто готовы выкладывать $$$, купят уже отлаженный оракл, а не твою СУБД. Те кто не готов выкладывать $$$, зачем им СУБД? У них MySQL, MSSQL, sqlite есть

В чем смысел?

Кстати, это не ты разрабатываешь глобальную и надежную СУБД на PHP http://habrahabr.ru/blogs/i_am_insane/70140/ ?

>а уж как неэффективно умеют пользователи писать запросы - так это отдельная история

Пользователи вообще не пишут запросы и не должны

http://artamonov.ru/2009/02/17/column-oriented-databases/

Мож, они с автором топика единомышленники и напишут вместе свою СУБД?

> Пользователи вообще не пишут запросы и не должны

пользователи СУБД, не зацикливайтесь на десктопных определениях

>Пользователи вообще не пишут запросы и не должны

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

> Скажем так, СУБД кроме оракла на данный момент настолько убоги что о них вообще говорить не хочется

хм.. и чем же, например, db2 хуже оракла?

> Хочется сделать большой упор на кластеризацию (в том числе и распределённую, когда один сервер в германии, другой в россии).

ты смотрел в сторону mongodb, couchdb, etc?
почему ты решил писать именно реляционную бд?

> ну не файловую но систему распределённого хранения данных по некоему rowid. желательно ещё и с софтварным распределённым raid.

ты смотрел в сторону glusterfs?

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

Ъ - это удобный и эффективный ORM, а потом вся бизнес-логика в нормальном высокоуровневом языке. Остальное - от лукавого!

ЗЫ Да, я жаваписец!

Кстати, а вот если бы вы решили удивить мир правильной (быстрой, удобной, ...) свободной ООБД - это было б действительно круто! А реляционная годится только как максимально незаметная подкладка под ORM...

кстати странно почему в топике никто не вспомнил про фаерберд

чем он не устраивает? хранимые процедуры есть, триггеры есть, свободная лицензия есть

>Ищу коллег для разработки СУБД

Бросьте вы это занятие. SQL уже мёртв. Лучше придумайте что нить другое.

> хранимые процедуры есть, триггеры есть

нормальных функций нет.

> так где ты собственно предлагаешь хранить функцию ПРИБЫЛЬНОСТЬ()? Если в БД это тогда как раз и будет "ЛОГИКА В БД"

Неа. Функция ПРИБЫЛЬНОСТЬ() это инструмент анализf данных (элемент OLAP), и это нормально - любая современная пригодная к эксплуатции СУБД поддерживает такие функции.

А "логика в БД" это процедура СОЗДАТЬ_СЧЕТФАКТУРУ_ИЗ_НАКЛАДНОЙ() - и вот уже этого и надо чураться.