LINUX.ORG.RU
ФорумTalks

документирование структуры БД в вики, почему да/нет?


0

0

проект маленький. десяток табличек, которые весьма редко меняются. девелопер ленивый. %-) спецтулзами шарахать тоже неохота. искал чего попроще, чтобы все прочесть могли. вики уже стоит, создал страницу, где для каждой таблицы приведено краткое «зачем», SQL создания, описание полей.

вопрос: ещё кто-то так делает?

из недостатков вижу необходимость руками править описания, если меняются базы (хотя никто не мешает сделать скрипт-синхронизатор, но в исходниках проекта каменты к SQL мешают по некоторым причинам %-( ).

из достоинств — вики уже была, отчего бы не использовать? структура меняется не часто, править тоже не придётся сильно. и просмотр/минимальная коррекция очень удобна.

но мучает вопрос: а не проглядел ли я какой верный подход ко всему этому? только не всякие там UML-ки рисовать, что-то такое же простое, как вики, но ещё проще и удобней. что скажут Коллективный Разум и Неколлективные Регистранты?

зыж а, да. проект на Глобальном и Надёжном.


Для десятка табличек хоть в ворде пиши. Вот для сотни тысяч таблиц с сотней приложений, и всё переплетено, wiki незаменима. Точнее без неё всё просто остановилось бы.

anonymous
()
Ответ на: комментарий от anonymous

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

engage
() автор топика
Ответ на: комментарий от engage

Ну, для начала, у нормальных людей схема БД описана либо в SQL, либо на любом языке с любым ORM, либо как-то ещё. И хранится в репозитории. К этой схеме и пишутся коменты прямо в исходниках, обычно этого более чем достаточно. А если у вас схема существует только в самой БД и меняется прямо на ходу, руками, то рано или поздно огребёте проблем, это доказано.

anonymous
()
Ответ на: комментарий от anonymous

естественно, существует она в виде SQL-операторов, которые всё создают и закидывают необходимые начальные данные, чтобы пакет можно было отбутстрапить. только вот «разбавлять» SQL коментариями несколько нельзя. ну, вот так вот. самым минималом, разве что. а вики создана на основе этого SQL. с детальным пояснением, что за таблицы и поля, зачем, почему, какие вещи от чего зависят (потому что не самый новый MySQL и никаких вам foreign index'ов, etc) и так далее. натурально, я бы первый себя пристрелил, если б даже такого минимума не было.

просто ситуации наступают, когда микрокаментов не хватает. вот сложно пояснить в двух словах, почему в этом поле бывает '2', и на что это два влияет, и что будет, если '1'. и почему надо отследить и поправить вооон там, если стало '1'. (ну MySQL, да, с ограничением без хранимок и триггеров, которые тоже та фигня ещё; проект-то на десяток таблиц).

engage
() автор топика
Ответ на: комментарий от engage

> «разбавлять» SQL коментариями несколько нельзя

Почему? Ну на худой конец, используте что-то типа literal programming, а SQL и описание выдёргивайте из исходника простеньким препроцессором.

И потом, придумать такую тулзу, чтобы она автоматически синхронизировала информацию в свободной текстовой форме, которую вы забиваете в вику, с SQL-схемой — это AI-полная задача, лол. Единственный способ сделать так, чтоб схема и описание всегда соответствовали друг другу — держать всё в одном месте.

anonymous
()
Ответ на: комментарий от anonymous

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

engage
() автор топика
Ответ на: комментарий от engage

Руками. На wiki есть ссылка в репозиторий со скриптом и всё описывается, что какое поле хранит, какие приложения используют эту таблицу, какие триггеры/хранимки и т.д. Кто плохо описывает — ходит за пивом.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.