Текущая схема БД.
- WARP ItSelf
- Самый умный
- Posts: 1011
- Joined: Tue 15 Mar, 2005 23:19
- Contact:
Текущая схема БД.
Посоветуйте чего-нибудь, знающие люди.
Last edited by WARP ItSelf on Thu 01 Jan, 1970 01:00, edited 0 times in total.
Reason: Спрятана избыточно широкая картинка
Reason: Спрятана избыточно широкая картинка
Никто не знал, а я...
Re: Текущая схема БД.
сразу бросается в глаза наличие в таблицах текстовых полей и ссылок на таблицу с локализацией этих полей . зачем ? оно конечно удобно таблицы править когда сразу есть текст, но с точки зрения базы - избыточно.
и получается плагин (читай pr_plugin) это как категория ? внутри него куча ссылок на разные версии . привычнее (не значит правильнее ) когда плагин+версия это отдельная запись .
и получается плагин (читай pr_plugin) это как категория ? внутри него куча ссылок на разные версии . привычнее (не значит правильнее ) когда плагин+версия это отдельная запись .
Re: Текущая схема БД.
Не то, чтобы я сильно знаток … но частично присоединюсь к 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).
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).
- WARP ItSelf
- Самый умный
- Posts: 1011
- Joined: Tue 15 Mar, 2005 23:19
- Contact:
Re: Текущая схема БД.
1. По поводу "дублирования" информации. В основной таблице (например, pr_plugin) хранятся сведения на языке по умолчанию (в данном случае, английском). Их не может не быть. В таблице локализации может храниться любое количество локализаций этих сведений, но их уже может и не быть. Выложить обязательную информацию в таблицу локализации, значит всегда делать JOIN, что невыгодно.
2. По поводу ссылок - отдельную таблицу сделать можно, но на данный момент сделана не поддержка множества ссылок, а поддержка локализации. Нет смысла водить пользователя на английскую страницу форума, если есть русская.
3. User и Author понятия пересекающиеся, но не общие. Не все, кто пользователи могут быть авторами. Авторы, безусловно, пользователи. Пользователи - все, оставляющие комментарии. Авторы - те, кто контролирует информацию о плагинах.
3. Relation - MultiArc и сабплагины. Насчет флага связи идея хорошая. Не знаю, правда, про Parent, но в целом полезно.
4. По поводу версий и файлов. Плагин всегда один, а файлов у него может быть сколько угодно. В том числе и разных версий. Но в первую очередь: x86/x64/Far2/Far3/Src и т.п.
2. По поводу ссылок - отдельную таблицу сделать можно, но на данный момент сделана не поддержка множества ссылок, а поддержка локализации. Нет смысла водить пользователя на английскую страницу форума, если есть русская.
3. User и Author понятия пересекающиеся, но не общие. Не все, кто пользователи могут быть авторами. Авторы, безусловно, пользователи. Пользователи - все, оставляющие комментарии. Авторы - те, кто контролирует информацию о плагинах.
3. Relation - MultiArc и сабплагины. Насчет флага связи идея хорошая. Не знаю, правда, про Parent, но в целом полезно.
4. По поводу версий и файлов. Плагин всегда один, а файлов у него может быть сколько угодно. В том числе и разных версий. Но в первую очередь: x86/x64/Far2/Far3/Src и т.п.
Никто не знал, а я...
- WARP ItSelf
- Самый умный
- Posts: 1011
- Joined: Tue 15 Mar, 2005 23:19
- Contact:
Re: Текущая схема БД.
Ну, ты вынес ее на уровень интерпретатора, а я на уровень БД. Я вот не уверен, что на уровне интерпретатора оно проще. Проще, это если всю локализацию положить в одну таблицу, считая, что языки будут добавляться посредством добавления столбцов (вы будете смеяться, но мозилла сначала сделала как у меня, а потом именно так). Криво, зато быстро.
2 Max:
Предлагаю в рамках интеграции обсудить коллективно API для плагина PlugRing обновления плагинов. Предлагаю в качестве протокола что-нибудь XML-based.
2 Max:
Предлагаю в рамках интеграции обсудить коллективно API для плагина PlugRing обновления плагинов. Предлагаю в качестве протокола что-нибудь XML-based.
Никто не знал, а я...
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: Текущая схема БД.
Там на уровне интерпретатора одна функция "extract_lang_str". Все равно же вызываешь какую-то функцию, чтобы маскировать строку при выдаче. И это _все_ по локализации прикладного уровня, ни лишних таблиц, ни лишних запросов, ни лишних форм. Я сделал эту локализацию за пол-часа (после нескольких часов раздумий правда).
Минус - нельзя искать только по одному языку. С другой стороны это и плюс - сразу ищется по всем языкам .
Минус - нельзя искать только по одному языку. С другой стороны это и плюс - сразу ищется по всем языкам .
- WARP ItSelf
- Самый умный
- Posts: 1011
- Joined: Tue 15 Mar, 2005 23:19
- Contact:
Re: Текущая схема БД.
Ну, вопрос, конечно, теологический, но мой подход требует меньше знаний от конечного пользователя и, возможно, быстрее (поскольку выпиливание по XML занимает время). Но это надо мерить. В смысле функционала меня смущает только первый пункт (одно поле ввода для всех языков и от автора требуется знать, как указать, что дальше идет локализованный кусок).
Никто не знал, а я...
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: Текущая схема БД.
Ну, это легко решается, путем небольшой подсказки. Ну, например, как BB-коды на форуме вставляются...
Re: Текущая схема БД.
Может, все-таки выбрать языком по умолчанию великий и могучий? Все-таки отечественный продукт…WARP ItSelf wrote:1…хранятся сведения на языке по умолчанию (в данном случае, английском).
Имхо, дублирование полей – большее зло, чем джойны. Хотя, конечно, можно, и как предлагаете Вы. Интересно ознакомиться с мнением других участников форума.WARP ItSelf wrote:1....Выложить обязательную информацию в таблицу локализации, значит всегда делать JOIN, что невыгодно.
Лучше не спешить и сразу продумать структуру базы данных (в частности, требуется ли таблица с url-ссылками). БД имеет нехорошее свойство разрастаться, а изменять структуру a posteriori обычно довольно затратно (и по времени, и по усилиям).WARP ItSelf wrote: 2. По поводу ссылок - отдельную таблицу сделать можно, но на данный момент сделана не поддержка множества ссылок, а поддержка локализации. Нет смысла водить пользователя на английскую страницу форума, если есть русская.
Так планируется хранить последние x32- и x64-версии или все? Во втором случае:WARP ItSelf wrote:4. По поводу версий и файлов. Плагин всегда один, а файлов у него может быть сколько угодно. В том числе и разных версий. Но в первую очередь: x86/x64/Far2/Far3/Src и т.п.
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 (чтобы не выбирать потом все версии)?
Re: Текущая схема БД.
по теме локализации.
язык по умолчанию предполагает логику в php "если язык по умолчанию запрос 1 , иначе запрос 2."
держать два запроса, их поддерживать не разумно. джоин не такое уж и зло. да и на наших объемах.
язык по умолчанию предполагает логику в php "если язык по умолчанию запрос 1 , иначе запрос 2."
держать два запроса, их поддерживать не разумно. джоин не такое уж и зло. да и на наших объемах.
- WARP ItSelf
- Самый умный
- Posts: 1011
- Joined: Tue 15 Mar, 2005 23:19
- Contact:
Re: Текущая схема БД.
2 sonar:
JOIN у нас и так есть. Мне в текущей структуре нравится, что есть "обязательная" информация. И, кстати, прекратите говорить "дублирование", тут дублирования данных нету. В общем по этому пункту я хоть и колеблюсь, но не убедили пока.
2 LAT:
1. with_source больше нет с нами, это устаревшие данные.
2. Рейтинг, уж извините, какой есть. Если его все крутить будут в любую сторону, тоже будет неудобно. Автор может каждый день релизы выкладывать, чему тогда рейтинг ставить?
3. Про пункт с датами можно подумать, конечно. Но здесь скорее интересна историческая сторона "когда плагин попал на плагринг", чем время добавления каждого файла.
4. Про пункт 9 - тоже устаревшие данные. Уже так и сделано (убран plugin_id в pr_file). Это была лажа.
JOIN у нас и так есть. Мне в текущей структуре нравится, что есть "обязательная" информация. И, кстати, прекратите говорить "дублирование", тут дублирования данных нету. В общем по этому пункту я хоть и колеблюсь, но не убедили пока.
2 LAT:
1. with_source больше нет с нами, это устаревшие данные.
2. Рейтинг, уж извините, какой есть. Если его все крутить будут в любую сторону, тоже будет неудобно. Автор может каждый день релизы выкладывать, чему тогда рейтинг ставить?
3. Про пункт с датами можно подумать, конечно. Но здесь скорее интересна историческая сторона "когда плагин попал на плагринг", чем время добавления каждого файла.
4. Про пункт 9 - тоже устаревшие данные. Уже так и сделано (убран plugin_id в pr_file). Это была лажа.
Никто не знал, а я...
-
- Posts: 1351
- Joined: Fri 30 Nov, 2007 15:32
- Location: Крым
- Has thanked: 15 times
- Been thanked: 50 times
- Contact:
Re: Текущая схема БД.
Пара вопросов.
1. Зачем нужны is_ansi и is_unicode в таблице файлов? По идее версия фара должна однозначно определять это.
2. Зачем в списке операционных систем локализация (да и description в общем-то)?
1. Зачем нужны is_ansi и is_unicode в таблице файлов? По идее версия фара должна однозначно определять это.
2. Зачем в списке операционных систем локализация (да и description в общем-то)?
- WARP ItSelf
- Самый умный
- Posts: 1011
- Joined: Tue 15 Mar, 2005 23:19
- Contact: