Привет!

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

Были определены требования: параллельное редактирование / обсуждение (как в Google Docs), форвард- и реверс-инжиниринг, миграции, мультиплатформенность или реализация в виде веб-сервиса, простота интерфейса и внешний вид, позволяющий показать модель заказчикам на презентации. К сожалению, найти инструмент, который бы удовлетворял всем требованиям, да еще и был бы тесно интегрирован с не самой популярной Vertica нам не удалось и мы остановились на StarUML с ER-плагином.

Зато я нашел бизнес-идею, которую искал долгое время. Я четко увидел, каким будет инструмент для ER-моделирования, в который я влюблюсь. Я подумал, что я не уникален, и решил, что инструмент придется по вкусу еще тысячам IT-специалистов, которым нравится то же, что и мне. Я решил чесать там, где чешется, как советовали 37signals в замечательной книге "Rework", и начал работу над веб-приложением, позволяющим совместно работать над моделью БД в режиме реального времени, как это сделано для документов в Google Docs. Я поставил себе задачу сделать это приложение таким же быстрым и простым в использовании, как Basecamp, и таким же функциональным, как GitHub. Планка высока, но достижима.

Пожалуйста, помогите мне понять, какие требования вы предъявляете к инструменту для ER-моделирования, потратив пару минут на этот опрос .

Большое спасибо,
Борис.

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

guest_20040621 , должно быть, я неправильно представил основные цели проекта. "Красивые картинки" - далеко не самая важная вещь. Приоритет на совместном владении моделью и удобстве использования. Я не знаком с AquaFold, но первый скриншот, который я увидел на их сайте, содержал 4 меню одно над другим. С моей точки зрения такой UI не может называться простым и удобным. Согласен с тем, что часто для проектирования лучше подходит белая доска и описание в виде plain text. Но не всегда.

Вы правильно сказали, все уже придумано до меня. Поэтому я не называю то, чем занимаюсь, "стартапом". Это лишь попытка сделать уже придуманные вещи лучше и удобнее.

Спасибо за наводку на AquaFold, обязательно ознакомлюсь детальнее. С ER/Studio и ERWin знаком.

Программист-Любитель , комментирование таблиц/колонок - очень нужная вещь. Она, вобщем-то, есть почти в любом проекте, но обычно выносится в отдельный Excel. Если это включить в модель, пользоваться станет намного удобнее. Спасибо.

MasterZiv , 20 000 сущностей - это мощно, я работал максимум с моделями из 800 (банковская сфера). У каждого продукта свои преимущества и ограничения, поддержка такого количества элементов - удел enterprise систем. Область применения своего продукта я вижу в небольших-средних проектах (не более нескольких сотен сущностей и нескольких десятков пользователей).

Роман, существуют два вида продуктов: многофункциональные сложные комбайны и простые утилиты с ограниченной функциональностью. Первые пилят большие компании, уровня HP и IBM, пилят годами и большими командами. Вторые делаются в небольших группах или вообще отдельными разработчиками. Пример первой - Microsoft Word, второй - Notepad. Можно ли сказать, что Word лучше Notepad'а? По количеству функциональности - конечно, по простоте и скорости - точно нет. Именно поэтому я открываю notepad в десятки раз чаще, чем Word.

Я верю в простые продукты и люблю их. С ними намного проще работать и их намного проще разрабатывать. Они очень маневренные и легко приспосабливаются к новым требованиям. Кроме того, они могут быть расширены в более многофункциональные (но никогда не получится сделать наоборот).

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

авторЛично я не вижу смысла в инструменте, который позволяет в real-time отражать действия других, так же как и инструменты контроля версий (svn, git, mercurial) не находят в этом необходимости.
Инструменты контроля версий не находят в этом необходимости, т. к. контролируют версии исходного кода. Исходный код намного низкоуровневее, чем модель данных, соответственно в совместном владении куском кода заинтересовано намного меньше людей, чем в совместном владении куском диаграммы. Я участвовал в совещаниях, где 10 человек, сидящих в разных офисах, обсуждали схему БД, но над кодом работал только с 1-2 другими людьми за одной машиной. Я думал над тем, нужны ли real-time обновления, и пришел к выводу, что это было бы удобно - во время групповых обсуждений всплывает много вещей, которые лучше всего исправить "на лету".

авторКак уже заметили выше:
Выбрав без всяких аргументов М0 (13562674), как модель только (!) для поддержки структуры данных в модели нижнего уровня (РМД), Вы замораживаете все проблемы, с которыми приходится сталкиваться разработчикам

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

Роман, прежде всего спасибо за развернутый аргументированный ответ.

Я бы сказал ровно наоборот - как правило (но необязательно) в совместном владении "кодом" заинтересовано больше люде, чем совместным владением диаграммой, потому что логично - чем выше абстракция, тем меньшее число людей вовлечено в работу с ней (хотя это не обязательно).
Я согласен с тем, что в создание вовлечена часто не вся команда, а лишь ее часть, состоящая из людей, ответственных за data modeling. Однако справедливо и другое утверждение - чем выше абстракция, тем больше людей, на работу которых она влияет. Даже UI девелоперы, которые не занимаются моделированием данных напрямую, могут просматривать модель время от времени для того, чтобы понимать, на каком наборе сущностей основана система, над которой они работают.

Ну вот дали вы групповые изменения в риалтайме на модель, и что дальше? Кто ответственен за создание версии, базовой версии? 10 человек в реал тайме что то наизменяли в одной модели, она не проходит проверку на валидность, пять человек ушли домой. что дальше? кто ответственен за исправление чужих ошибок в этой риалтайм диаграмме? Что делать дальше если попытки исправления зашли в тупик?
Как правило, за редактирование модели ответственны 1-2 человека (базисты). Другая группа людей будет пользоваться этой моделью в своей работе (кодеры). Третья группа - это люди со стороны бизнеса, комментаторы (менеджмент, клиенты, люди, аналитики). Таким образом, у нас есть пара людей, которые будут править схему и еще десяток тех, кто будет выдвигать предложения и использовать ее for informational purposes. Когда я впервые начал задумываться о шаринге и совместной работе, я увидел два варианта - модель Google Docs, совместное редактирование в реальном времени, и модель GoToMeeting - один "ведущий", выполняющий какие-то действия на расшареном экране, и "наблюдатели", которые видят то, что он делает, и могут давать советы. При этом "ведущий" может передать контроль другому пользователю, став "наблюдателем". Я пока что склоняюсь к первому варианту, хотя мысли, которые Вы описали, меня посещали (да и технически это проще, не нужно думать об обработке конфликтов, когда один человек меняет имя таблицы, а другой ее удаляет). Короче, есть о чем подумать в плане реализации общего доступа. Однако в целесообразности его реализации у меня сомнений нет - я сам столкнулся с такой необходимостью, да и большинство людей, участвовавших в опросе, отметило эту фичу как желательную.

Я понял, что Вы имели в виду под "замораживанием" проблем. Я понимаю, что кроме моделирования физической структуры есть еще много вещей, помогающих делать неработающий код работающим продуктом. Я не говорю: "Эта штука делает всю вашу работу", я говорю: "Эта штука делает определенную часть вашей работы, но делает ее хорошо. Если вам нужно что-то еще, воспользуйтесь другими классными инструментами." Делая меньше, можно сделать лучше. Именно поэтому многие программисты, использующие IntelliJ IDEA со встроенным файловым браузером и плагином для исполнения SQL скриптов, используют специализированные средства, такие как Far и DBVisualizer вместо них. И это при всей продуманности и высочайшем качестве продуктов от JetBrains.