Shapelez 22 янв 2009 в 17:33

Схема БД Mediawiki (Wikipedia)

1 мин

1.5K

Я пиарюсь

+84

Комментарии 63

denisnomad 22 янв 2009 в 17:38

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

-2

jeje 22 янв 2009 в 17:41

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

DOKA 22 янв 2009 в 17:48

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

apelsinka 22 янв 2009 в 18:05

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

mamba 22 янв 2009 в 17:48

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

Animan 22 янв 2009 в 17:49

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

sunofvault 22 янв 2009 в 17:52

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

sp2k6 22 янв 2009 в 18:06

Mysql Workbench

-1

sp2k6 22 янв 2009 в 18:08

Ой. Не в нём:)

norguhtar 22 янв 2009 в 20:02

DbDesigner4 это.

RomanL 22 янв 2009 в 22:12

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

RomanL 22 янв 2009 в 22:25

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

НЛО прилетело и опубликовало эту надпись здесь

dizzyman 22 янв 2009 в 18:12

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

GarretUA 22 янв 2009 в 18:02

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

Darx 22 янв 2009 в 18:03

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

micktu 22 янв 2009 в 18:21

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

sevka_fedoroff 23 янв 2009 в 14:59

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

mgetman 22 янв 2009 в 18:20

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

Ghz 22 янв 2009 в 18:24

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

spycode 22 янв 2009 в 18:39

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

Hint 22 янв 2009 в 18:46

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

psylosss 22 янв 2009 в 19:21

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

Kalan 22 янв 2009 в 22:26

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

psylosss 22 янв 2009 в 22:29

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

vasilievvv 22 янв 2009 в 22:29

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

cucik 22 янв 2009 в 18:49

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

stfalcon 22 янв 2009 в 18:54

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

mkechinov 22 янв 2009 в 19:00

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

norguhtar 22 янв 2009 в 20:03

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

mephistopheies 22 янв 2009 в 19:36

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

vasilievvv 22 янв 2009 в 22:31

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

-1

ginius 23 янв 2009 в 10:05

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

vasilievvv 23 янв 2009 в 17:50

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 23 янв 2009 в 23:17

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

ginius 23 янв 2009 в 10:08

Согласен.

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

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

vasilievvv 23 янв 2009 в 17:55

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

milax 22 янв 2009 в 20:01

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

m007 22 янв 2009 в 20:17

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

vasilievvv 22 янв 2009 в 22:36

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

LighteR 22 янв 2009 в 20:33

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

ginius 23 янв 2009 в 10:09

oldmans style :)

MpaK999 22 янв 2009 в 20:42

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

vasilievvv 22 янв 2009 в 22:32

Из 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 22 янв 2009 в 23:10

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

vasilievvv 22 янв 2009 в 23:13

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

mrgall 23 янв 2009 в 00:25

А кто

mrgall 23 янв 2009 в 00:26

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

CBuH 22 янв 2009 в 21:46

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

Kalan 22 янв 2009 в 22:25

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

LDEV 22 янв 2009 в 22:36

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

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

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

vasilievvv 22 янв 2009 в 22:38

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

vasilievvv 22 янв 2009 в 22:43

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 22 янв 2009 в 22:53

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

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

slaventium 23 янв 2009 в 00:20

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

Boriskin 23 янв 2009 в 00:22

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

zol 23 янв 2009 в 00:47

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

Kalan 23 янв 2009 в 01:20

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

zol 23 янв 2009 в 01:31

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

RomanL 23 янв 2009 в 12:11

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

zol 26 янв 2009 в 10:53

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

mkechinov 23 янв 2009 в 12:56

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

mkechinov 23 янв 2009 в 13:12

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время