Схема БД Mediawiki (Wikipedia)

[@denisnomad]

Я вижу — он откинулся на стул справа и с улыбкой смотрит в монитор (так и хочется сказать, в iMac). Я опасносте?

[@jeje]

Просто и со вкусом, мне бы такую в проект.

[@DOKA]

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

[@apelsinka]

о да… пришлось как-то доделывать корявый проект со схемой бд на А2 11 шрифтом :( ни описаний, ни комментариев, ни документации, кроме этого плаката не было. вспоминаем как страшный сон.

[@mamba]

А цвета-то какие гламурненькие))

[@Animan]

А логический уровень нету?

[@sunofvault]

Наредкость понятная и маленькая, я думал там все хуже
Все красиво и аккуратно, а в чем схему делали? :)

[@sp2k6]

Mysql Workbench

[@sp2k6]

Ой. Не в нём:)

[@norguhtar]

DbDesigner4 это.

[@RomanL]

Симпатичненько… а то мне ERWin уже надоел. Да и неприспособлен он под MySQL — приходится кой что ручками править.

[@RomanL]

Так… это все замечательно (там даже импорт из ERWin'а есть), но почему там нет логического представления!!!??? Это ужасно :(

[@dizzyman]

Ни ого, а ага! 40 табличек для такого проекта считаю вполне приемлемым и даже отличным :))

[@GarretUA]

DbDesigner отличная вещь! :)

[@Darx]

Спасибо, что просветили =)

[@micktu]

Visio — отличная вещь. OmniGraffle — отличная вещь.

[@sevka_fedoroff]

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

[@mgetman]

Нде, посмотрел на свою курсовую по БД и понял, что ещё учиться и учиться.

[@Ghz]

Похоже на мой курсач)

[@spycode]

Ничего удивительного и интересного не обнаружил. Правда, предаставлял что-то по сложнее и навароченне, но на самом, то деле что проще и понятнее то и првильнее.

[@Hint]

Никак не могу понять, почему timestamp хранят в char(14), а не в int.

[@psylosss]

видимо, учитывают часовой пояс

[@Kalan]

Часовой пояс настраивается исключительно в настройках зарегистрированного пользователя, всё хранится и обрабатывается в UTC.

[@psylosss]

Честно говоря, предположил пальцем в небо. Тогда действительно, для чего же char(14)?

[@vasilievvv]

Изначально они хранились в MySQL'евском формате (TIMESTAMP), который задаётся в виде (YYYMMDDHHMMSS), но потом из-за многочисленных проблем их переделали

[@cucik]

Увидел схему БД wiki, и вспомнил про свою потребность. Господа, подскажите пожалуйста бесплатный софт для проектирования БД по Mac OS. Mysql Workbench Mac не подходит. «Мутная» и достаточно глючная софтина. Кроме возможности создание схем от программы ничего не требуется. Заранее спасибо.

[@stfalcon]

когда делали проект на движке mediawiki я напечатал её на 4х листах А4 и склеил в кучу и повесил на стену. довольно удобно

[@mkechinov]

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

[@norguhtar]

Для чисто рисования табличек рекомендую Visual Paradigm for UML. Там есть нотация для СУБД.

[@mephistopheies]

Кто то там сказал про «приятно смотреть на хорошо спроектированную БД». Честно говоря не согласен. Например таблица oldimages, в состав первичного ключа входит варчар, ну или в таблице image пк только варчар. Может это фича канешна, но буду благодарен если кто разъяснит.

[@vasilievvv]

Не вижу там первичного ключа вообще в этой таблице

[@ginius]

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

[@vasilievvv]

CREATE INDEX /*i*/oi_usertext_timestamp ON /*_*/oldimage (oi_user_text,oi_timestamp);
CREATE INDEX /*i*/oi_name_timestamp ON /*_*/oldimage (oi_name,oi_timestamp);
CREATE INDEX /*i*/oi_name_archive_name ON /*_*/oldimage (oi_name,oi_archive_name(14));
CREATE INDEX /*i*/oi_sha1 ON /*_*/oldimage (oi_sha1);

Где тут первичный ключ?

[@ginius]

Откуда это? Я вижу только картинку. На ней нарисована таблица, на ней обозначен ключ ровно как я описал выше.

[@ginius]

Согласен.

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

Как вариант они хранят там гуид для работы базы в кластере (чисто догадка — с mysql почти не работал)

[@vasilievvv]

И каким образом использование имени файла в качестве первичного ключа является признаком плохого проектирования?

[@milax]

Думал, что структура БД у такого ресурса сложнее, но не тут то было. Молодцы проектировщики.

[@m007]

Много таблиц это не значит сложно. Оптимальная структура из минимума таблиц это как раз и сложнее сделать чем неоптимально 250 таблиц налепить.

[@vasilievvv]

Если учитывать, что для внесения изменения в существующие таблицы MediaWiki системным администраторам MediaWiki приходится проводить танцы с бубном (смена master-сервера, обновление баз данных на всех slave'ах, ещё одна смена, и так три раза), то стремление разработчиков толково делать схему понятно

[@LighteR]

А оправдана ли расстановка префиксов в названиях полей если это не внешние ключи?

[@ginius]

oldmans style :)

[@MpaK999]

э, не понял только почему дату хранят в временные параметры в char(14) (хранят как строку?), а не к примеру datetime, чтобы использовать в дальнейшем операции с датами?

[@vasilievvv]

Из SQL:
— The MySQL table backend for MediaWiki currently uses
— 14-character BINARY or VARBINARY fields to store timestamps.
— The format is YYYYMMDDHHMMSS, which is derived from the
— text format of MySQL's TIMESTAMP fields.
— — Historically TIMESTAMP fields were used, but abandoned
— in early 2002 after a lot of trouble with the fields
— auto-updating.
— — The Postgres backend uses DATETIME fields for timestamps,
— and we will migrate the MySQL definitions at some point as
— well.

[@MpaK999]

э, получается в мускуле это наследие времён, в постгри всё в норме, а в мускуле будут изменения когда будет время :)

[@vasilievvv]

Ну да. А обновлять это на миллионах строк никто не будет. Слишком маразматично

[@mrgall]

А кто

[@mrgall]

А кто мешент использовать операции с UNIX TIMESTAMP?
По моим наблюдениям так даже удобней.

[@CBuH]

«Нажимабельно; если долго смотреть на схему, то можно увидеть призрак Джимми Уэлса.»
Он разве скончался? о_О

[@Kalan]

Как человек — да. В награду за свои заслуги он теперь одно из Высших Существ и потому может находиться в суперпозиции. ;)

[@LDEV]

Уфф, а я то думал, что в дебрях mysql-кластера wiki-педии тысячи таблиц, сотни слейв-серверов…

А тут прям на экран почти влезает :)

Помнится у них где-то было описание сетевой архитектуры проекта, и серверов. Может кинет кто ссылку?

[@vasilievvv]

leuksman.com/images/f/f3/Scaling_LAMP_(PDF).pdf — тут базово описывается. Сча поищу более детальные описания

[@vasilievvv]

meta.wikimedia.org/wiki/Servers — описание
upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Wikimedia-servers-2008-11-10.svg/1024px-Wikimedia-servers-2008-11-10.svg.png — схемка
wikitech.wikimedia.org/view/Main_Page — внутренний сайт системных администраторов; мало понятно, но зато наиболее актуально

[@LDEV]

10x! Очень познавательно!

Наверно тот же вконтакте по похожей архитектуре живёт.

[@slaventium]

Простите за ламерский вопрос, а что это за тип поля такой: tinytext?

[@Boriskin]

Это маленький текст) мааасенький такой совсем))

[@zol]

А вот интересно посмотреть на схему социальной сети по подобию хабра, что бы также красиво и толково составлено. Может кто-то видел? Буду признателен если ссылочку кинете. Как раз изучаю такое.

[@Kalan]

Можно поставить livestreet.ru и посмотреть.

[@zol]

ну это я знаю :)
но что бы составить самому на него вот такой граф надо его изучить

[@RomanL]

Есть такая штука как Reverse Engineering (так вроде пишется) в том же, описываемом здесь DbDesigner'e — это когда вы указываете параметры доступа к базе, а программка вытаскивает из нее структурную информацию и оформляет в виде вот таких вот картиночек. Очень познавательный процесс. Рекомендую :)

[@zol]

во первых спасибо за подсказку и вправду не плохо получается
токо вот самое главное (вязи между таблицами) он не даёт

[@mkechinov]

Кто-нибудь может что-нибудь полезное сказать, почему DBDesigner сам переименовывает поле status в status_2?

[@mkechinov]

Вопрос снят.
options -> dbdesigner options->database options->reserved words