Текущая схема БД.

Здесь можно обсудить сайт PlugRinG и предложить идеи по его дальнейшему развитию.
User avatar
WARP ItSelf
Самый умный
Posts: 1011
Joined: Tue 15 Mar, 2005 23:19
Contact:

Текущая схема БД.

Postby WARP ItSelf » Fri 17 Jun, 2011 23:48


Посоветуйте чего-нибудь, знающие люди.
Last edited by HaRT on Sat 18 Jun, 2011 17:42, edited 1 time in total.
Reason: Спрятана избыточно широкая картинка
Никто не знал, а я...

User avatar
ctapmex
Posts: 990
Joined: Fri 11 Apr, 2008 07:53
Been thanked: 2 times
Contact:

Re: Текущая схема БД.

Postby ctapmex » Sat 18 Jun, 2011 15:27

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

LAT
Posts: 159
Joined: Thu 21 Jan, 2010 20:00
Has thanked: 5 times
Been thanked: 3 times

Re: Текущая схема БД.

Postby LAT » Mon 20 Jun, 2011 13:16

Не то, чтобы я сильно знаток … но частично присоединюсь к sonar’у.
1. title/description уже есть в pr_plugin_locale, в pr_plugin эти поля тогда просто дублируется. Аналогично для title/description в pr_category и pr_category_locale. Аналогично для name/surname/middlename/description в pr_author и pr_author_locale. Аналогично для title/description в pr_programming_language и pr_programming_language_locale. Аналогично для title/short_title/description в pr_operating_system и pr_operating_system_locale.
2. pr_plugin. forum_url – если ссылка на описание плагина на форуме в единственном экземпляре, она продублируется в pr_plugin и несколько раз (для каждого языка) в pr_plugin_locale. Тогда, имхо, лучше убрать поле из pr_plugin_locale. Если ссылок может быть несколько – наверное, лучше выделить отдельную таблицу { plugin_id, url, description } (description – описание, что конкретно находится по этой ссылке – сам плагин, его обсуждение, описание багов, мануалы, страница плагина, упоминание плагина на сторонних сайтах, старые/новые ветки обсуждения и т.д.)
3. pr_user: служит для хранения пользователей, оставляющих сообщения на плагринге, или для определения, кто из пользователей упоминал об авторе плагина? В 1-м случае, author_id можно будет определять через pr_user, pr_plugin_comment и pr_plugin_to_author. Хотя не принципиально.
4. pr_file. visible_filename varchar(300) – кажется, многовато. А filename – это ссылка на файл?
5. pr_plugin. Не понял, зачем license, если есть license_id.
6. Не понятно, что содержит таблица pr_plugin_to_relation. Это связь плагинов в смысле – выполняющие те же функции (например, замена с использованием регэкспов) - или это связь плагинов в смысле – плагины, требующиеся для работы данного плагина? Во втором случае можно добавить поле вид_связи и перенести из pr_plugin в pr_plugin_to_relation поле parent_id.
UPD. Убрал лишние пункты. Я вначале сгоряча решил, что в БД планируется хранить информацию обо всех версиях плагинов (и для этого предназначены pr_plugin_to_file и pr_file). :wacko:

User avatar
WARP ItSelf
Самый умный
Posts: 1011
Joined: Tue 15 Mar, 2005 23:19
Contact:

Re: Текущая схема БД.

Postby WARP ItSelf » Mon 20 Jun, 2011 16:05

1. По поводу "дублирования" информации. В основной таблице (например, pr_plugin) хранятся сведения на языке по умолчанию (в данном случае, английском). Их не может не быть. В таблице локализации может храниться любое количество локализаций этих сведений, но их уже может и не быть. Выложить обязательную информацию в таблицу локализации, значит всегда делать JOIN, что невыгодно.

2. По поводу ссылок - отдельную таблицу сделать можно, но на данный момент сделана не поддержка множества ссылок, а поддержка локализации. Нет смысла водить пользователя на английскую страницу форума, если есть русская.

3. User и Author понятия пересекающиеся, но не общие. Не все, кто пользователи могут быть авторами. Авторы, безусловно, пользователи. Пользователи - все, оставляющие комментарии. Авторы - те, кто контролирует информацию о плагинах.

3. Relation - MultiArc и сабплагины. Насчет флага связи идея хорошая. Не знаю, правда, про Parent, но в целом полезно.

4. По поводу версий и файлов. Плагин всегда один, а файлов у него может быть сколько угодно. В том числе и разных версий. Но в первую очередь: x86/x64/Far2/Far3/Src и т.п.
Никто не знал, а я...

User avatar
Max Rusov
Posts: 3599
Joined: Wed 23 Nov, 2005 11:11
Location: Москва-Питер
Been thanked: 6 times
Contact:

Re: Текущая схема БД.

Postby Max Rusov » Mon 20 Jun, 2011 16:10

Я у себя сделал локализацию вот так. По моему, это гораздо проще.

User avatar
WARP ItSelf
Самый умный
Posts: 1011
Joined: Tue 15 Mar, 2005 23:19
Contact:

Re: Текущая схема БД.

Postby WARP ItSelf » Mon 20 Jun, 2011 16:16

Ну, ты вынес ее на уровень интерпретатора, а я на уровень БД. Я вот не уверен, что на уровне интерпретатора оно проще. Проще, это если всю локализацию положить в одну таблицу, считая, что языки будут добавляться посредством добавления столбцов (вы будете смеяться, но мозилла сначала сделала как у меня, а потом именно так). Криво, зато быстро.

2 Max:

Предлагаю в рамках интеграции обсудить коллективно API для плагина PlugRing обновления плагинов. Предлагаю в качестве протокола что-нибудь XML-based.
Никто не знал, а я...

User avatar
Max Rusov
Posts: 3599
Joined: Wed 23 Nov, 2005 11:11
Location: Москва-Питер
Been thanked: 6 times
Contact:

Re: Текущая схема БД.

Postby Max Rusov » Mon 20 Jun, 2011 16:24

Там на уровне интерпретатора одна функция "extract_lang_str". Все равно же вызываешь какую-то функцию, чтобы маскировать строку при выдаче. И это _все_ по локализации прикладного уровня, ни лишних таблиц, ни лишних запросов, ни лишних форм. Я сделал эту локализацию за пол-часа (после нескольких часов раздумий правда).
Минус - нельзя искать только по одному языку. С другой стороны это и плюс - сразу ищется по всем языкам :).

User avatar
WARP ItSelf
Самый умный
Posts: 1011
Joined: Tue 15 Mar, 2005 23:19
Contact:

Re: Текущая схема БД.

Postby WARP ItSelf » Mon 20 Jun, 2011 16:44

Ну, вопрос, конечно, теологический, но мой подход требует меньше знаний от конечного пользователя и, возможно, быстрее (поскольку выпиливание по XML занимает время). Но это надо мерить. В смысле функционала меня смущает только первый пункт (одно поле ввода для всех языков и от автора требуется знать, как указать, что дальше идет локализованный кусок).
Никто не знал, а я...

User avatar
Max Rusov
Posts: 3599
Joined: Wed 23 Nov, 2005 11:11
Location: Москва-Питер
Been thanked: 6 times
Contact:

Re: Текущая схема БД.

Postby Max Rusov » Mon 20 Jun, 2011 16:53

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

LAT
Posts: 159
Joined: Thu 21 Jan, 2010 20:00
Has thanked: 5 times
Been thanked: 3 times

Re: Текущая схема БД.

Postby LAT » Tue 21 Jun, 2011 10:21

WARP ItSelf wrote:1…хранятся сведения на языке по умолчанию (в данном случае, английском).
Может, все-таки выбрать языком по умолчанию великий и могучий? Все-таки отечественный продукт…

WARP ItSelf wrote:1....Выложить обязательную информацию в таблицу локализации, значит всегда делать JOIN, что невыгодно.
Имхо, дублирование полей – большее зло, чем джойны. Хотя, конечно, можно, и как предлагаете Вы. Интересно ознакомиться с мнением других участников форума.

WARP ItSelf wrote: 2. По поводу ссылок - отдельную таблицу сделать можно, но на данный момент сделана не поддержка множества ссылок, а поддержка локализации. Нет смысла водить пользователя на английскую страницу форума, если есть русская.
Лучше не спешить и сразу продумать структуру базы данных (в частности, требуется ли таблица с url-ссылками). БД имеет нехорошее свойство разрастаться, а изменять структуру a posteriori обычно довольно затратно (и по времени, и по усилиям).

WARP ItSelf wrote:4. По поводу версий и файлов. Плагин всегда один, а файлов у него может быть сколько угодно. В том числе и разных версий. Но в первую очередь: x86/x64/Far2/Far3/Src и т.п.
Так планируется хранить последние x32- и x64-версии или все? Во втором случае:
7. pr_plugin. Как-то нелогично делать raiting сразу для всех версий плагина: что получится, если 1-я версия была хреновой, а 2-я – замечательной? Или это поле касается последней версии?
8. pr_file. Можно добавить дату создания конкретной версии плагина date_created (в pr_plugin, я так понял, это будет либо дата создания 1-й версии, либо дата создания последней версии). То же самое насчет date_added. Правда, тогда эти поля продублируются (и нужны ли они будут?) в pr_plugin.
9. В pr_file можно добавить поле plugin_id – это позволит избавиться от таблицы pr_plugin_to_file и лишнего джойна. Все равно вся информация по версиям хранится (насколько я понял) в pr_file, а pr_plugin_to_file – всего лишь переходник.
10. [Спорно] Может, добавить в pr_plugin поле last_version (чтобы не выбирать потом все версии)?

LAT
Posts: 159
Joined: Thu 21 Jan, 2010 20:00
Has thanked: 5 times
Been thanked: 3 times

Re: Текущая схема БД.

Postby LAT » Tue 21 Jun, 2011 10:57

11. pr_plugin. with_source относится к отдельному файлу (отдельной версии плагина), а не ко всему плагину сразу? Если да – в pr_plugin это поле, наверное, лишнее.

User avatar
ctapmex
Posts: 990
Joined: Fri 11 Apr, 2008 07:53
Been thanked: 2 times
Contact:

Re: Текущая схема БД.

Postby ctapmex » Tue 21 Jun, 2011 10:59

по теме локализации.
язык по умолчанию предполагает логику в php "если язык по умолчанию запрос 1 , иначе запрос 2."
держать два запроса, их поддерживать не разумно. джоин не такое уж и зло. да и на наших объемах.

User avatar
WARP ItSelf
Самый умный
Posts: 1011
Joined: Tue 15 Mar, 2005 23:19
Contact:

Re: Текущая схема БД.

Postby WARP ItSelf » Wed 22 Jun, 2011 00:44

2 sonar:

JOIN у нас и так есть. Мне в текущей структуре нравится, что есть "обязательная" информация. И, кстати, прекратите говорить "дублирование", тут дублирования данных нету. В общем по этому пункту я хоть и колеблюсь, но не убедили пока.

2 LAT:

1. with_source больше нет с нами, это устаревшие данные.
2. Рейтинг, уж извините, какой есть. Если его все крутить будут в любую сторону, тоже будет неудобно. Автор может каждый день релизы выкладывать, чему тогда рейтинг ставить?
3. Про пункт с датами можно подумать, конечно. Но здесь скорее интересна историческая сторона "когда плагин попал на плагринг", чем время добавления каждого файла.
4. Про пункт 9 - тоже устаревшие данные. Уже так и сделано (убран plugin_id в pr_file). Это была лажа.
Никто не знал, а я...

Ariman
Posts: 1131
Joined: Fri 30 Nov, 2007 15:32
Location: Крым
Has thanked: 7 times
Been thanked: 22 times
Contact:

Re: Текущая схема БД.

Postby Ariman » Wed 22 Jun, 2011 08:56

Пара вопросов.

1. Зачем нужны is_ansi и is_unicode в таблице файлов? По идее версия фара должна однозначно определять это.
2. Зачем в списке операционных систем локализация (да и description в общем-то)?

User avatar
WARP ItSelf
Самый умный
Posts: 1011
Joined: Tue 15 Mar, 2005 23:19
Contact:

Re: Текущая схема БД.

Postby WARP ItSelf » Wed 22 Jun, 2011 09:14

1. Устаревшие данные.
2. А хрен его знает.
Никто не знал, а я...

User avatar
ctapmex
Posts: 990
Joined: Fri 11 Apr, 2008 07:53
Been thanked: 2 times
Contact:

Re: Текущая схема БД.

Postby ctapmex » Wed 22 Jun, 2011 09:31

Ariman wrote:Пара вопросов.

1. Зачем нужны is_ansi и is_unicode в таблице файлов? По идее версия фара должна однозначно определять это.


а что мешает дорабатываться анси плагину для far >=2 ?


Return to “Обсуждение PlugRinG”

Who is online

Users browsing this forum: No registered users and 1 guest