Структура и описание таблиц BOSS`а
  • GoDrGoDr Декабрь 2011
    Аркадий, можешь сделать описание каждой таблицы и поля в неё? Пытаюсь начать писать расширения на базе J1.4, но не хватает знаний.. Конечно я смогу разобраться сам, но жалко время терять если ты это сможешь сделать ;)
  • ArkadiyArkadiy Декабрь 2011
    Таблица категорий
    jos_boss_1_categories
    1 id ид
    2 parent дочерняя категория
    3 name Наименование
    4 slug Алиас для ссылки
    5 meta_title
    6 meta_desc
    7 meta_keys
    8 description описание
    9 ordering порядок
    10 published публикация
    11 content_types основной тип контента для категории
    12 template шаблон категории
    13 rights права
    Отредактированно Arkadiy в 2011-12-05 10:15:00
  • ArkadiyArkadiy Декабрь 2011
    Таблица связей категорий с контентом
    #__boss_".$id."_content_category_href`
    `id`
    `category_id` ид категории
    `content_id` ид контента
  • ArkadiyArkadiy Декабрь 2011
    Таюлица контента
    `#__boss_".$id."_contents`
    `id`
    `name`
    `slug`
    `meta_title`
    `meta_desc`
    `meta_keys`
    `userid` ид автора
    `published`
    `frontpage` публикация на главной странице
    `featured` выделение контента индивидуальным шаблоном
    `date_created` дата создания
    `date_last_сomment` дата послед. комментария
    `date_publish` дата публикации
    `date_unpublish` дата снятия с пуб.
    `views` кол-во просмотров
    `type_content` тип контента
    `ordering` порядок

    Сюда-же пишутся другие поля, создаваемые в админке.
    Отредактированно Arkadiy в 2011-12-05 10:20:12
  • ArkadiyArkadiy Декабрь 2011
    Таблица стандартных настроек поля
    `#__boss_".$id."_fields` ( ".
    `fieldid` ид поля
    `name` имя поля в БД
    `title` название
    `display_title` показывать название на фронте
    `description` описание
    `type` тип поля
    `text_before` текс перед выводом поля на фронте
    `text_after` текс после вывода поля на фронте
    `tags_open` тег открывающий вывод поля
    `tags_separator` разделяющий тег
    `tags_close` закрывающий тег
    `maxlength` макс. длина контента поля
    `size` хз, не помню
    `required` обязательно для заполнения
    `link_text`
    `link_image`
    `ordering` порядок поля в админке
    `cols` колонок (для текстареа)
    `rows` строк (для текстареа)
    `profile` поле относится к контенту или профилю пользователя
    `editable` редактируемое с фронта
    `searchable` Участвует в поиске?
    `sort` сортировка по умолчанию
    `sort_direction` направление сортировки
    `catsid` привязка поля к типам контента
    `published` публикация
  • ArkadiyArkadiy Декабрь 2011
    Таблица дополнительных настроек поля
    `#__boss_".$id."_field_values`
    `fieldvalueid` ид
    `fieldid` ид поля
    `fieldtitle` название настройки
    `fieldvalue` значение настройки
    `ordering` порядок
    `sys` не исп.
  • ArkadiyArkadiy Декабрь 2011
    Таблица позиций шаблона
    `#__boss_".$id."_groups`
    `id` ид
    `name` название позиции
    `desc` описание позиции
    `template` шаблон в котором есть это поле
    `type_tmpl` шаблон категории или контента
    `catsid` категории в которых отображается позиция
    `published` публикация
  • ArkadiyArkadiy Декабрь 2011
    Таблица привязки полей к позициям шаблона
    `#__boss_".$id."_groupfields`
    `fieldid` ид поля
    `groupid` ид позиции шаблона
    `template` шаблон позиции
    `type_tmpl` шаблон категории или контента
    `ordering` порядок вывода на фронт если поле в позиции не одно.
  • ArkadiyArkadiy Декабрь 2011
    Таблица встроенного рейтинга
    `#__boss_".$id."_rating`
    `id` ид
    `contentid` ид контента
    `userid` ид проголосовавшего пользователя
    `note` оценка
    `ip` айпи проголосовавшего пользователя
    `date` дата голосования
    `published` публикация
  • ArkadiyArkadiy Декабрь 2011
    Таблица встроенных комментариев
    `#__boss_".$id."_reviews`
    `id` ид
    `contentid` ид контента
    `userid` ид комментировавшего пользователя
    `title` заголовок
    `description` комментарий
    `date` дата комментария
    `published` публикация
  • GoDrGoDr Декабрь 2011
    отлично!...
    Вопрос может не совсем в тему.. а на сколько оправдано для $id создавать отдельную таблицу?
  • ArkadiyArkadiy Декабрь 2011
    Таблица типов контента
    `#__boss_".$id."_content_types`
    `id` ид
    `name` наименование
    `desc` описанние
    `fields` поля, привязанные к типу контента
    `published` публикация
    `ordering` порядок
  • ArkadiyArkadiy Декабрь 2011
    Таблица профиля пользователя
    `#__boss_".$id."_profile`
    `userid` ид пользователя.
  • ArkadiyArkadiy Декабрь 2011
    Конфигурация
    `#__boss_config`
    `id` ид
    `name` Название каталога
    `slug` Алиас каталога
    `meta_title`
    `meta_desc`
    `meta_keys`
    `default_order_by` сортировка по умолчанию
    `contents_per_page` контента на страницу
    `root_allowed` разрешить контент в родительских категориях
    `show_contact` показывать контакты
    `send_email_on_new` отправлять майл о новом контенте
    `send_email_on_update` отправлять майл об отредактированном контенте
    `auto_publish` автопубликация/модерация публикации контента
    `fronttext` Текст на главной
    `email_display` способ показа майла
    `display_fullname` способ показа ФИО
    `rules_text` текст правил
    `expiration` разрешить устаревание контента
    `content_duration` время жизни контента
    `recall` оповещать автора об окончании публикации контента
    `recall_time` за сколько дней оповещать
    `recall_text` текст оповещения
    `empty_cat` показывать пустые категории
    `cat_max_width` ширина картинки категории
    `cat_max_height` высота картинки категории
    `cat_max_width_t` ширина миниатюры категории
    `cat_max_height_t` высота миниатюры категории
    `submission_type` способ авторизации при добавлении контента с фронта
    `nb_contents_by_user` макс. кол-во контента от одного автора
    `allow_attachement` разрешить вложения
    `allow_contact_by_pms` разрешить личные сообщения
    `allow_comments` разрешить комментарии
    `rating` выбор плагина рейтингов
    `secure_comment` капча при комментировании
    `comment_sys` плагин комментариев
    `allow_unregisered_comment` комментари от незарег. пользователей
    `allow_ratings` разрешить рейтинг
    `secure_new_content` капча при добавлении контента
    `use_content_mambot` разрешить мамботы в контенте
    `show_rss` разрешить rss
    `filter` выбор плагина фильтра контента
    `template` шаблон каталога
    `allow_rights` разрешить управление правами пользователей
    `rights`права пользователей на каталог
  • ArkadiyArkadiy Декабрь 2011
    отлично!...
    Вопрос может не совсем в тему.. а на сколько оправдано для $id создавать отдельную таблицу?

    $id - это отдельный каталог, все каталоги независимы друг от друга процентов на 90, разные таблицы для разных каталогов оправданы на большом количестве контента и большой разнице в типах контента.
  • GoDrGoDr Декабрь 2011
    Аркадий, вот смотри... Структура у таблиц - константа. Значит по сути таблицы разных каталогов одинаковы. Теперь просто порассуждаем (я ни в коем случае не против того что есть, я только начал "ломать" J1.4+BOSS)
    На сколько я успел заметить, такая структура не очень привычна для меня, я бы даже сказал не очень оптимальна, для создания расширений. Поясню почему.. Запрос к базе проще делать к одной таблице (или связанной с ней таблицами) чем к нескольким. И нагрузка меньше и поиск быстрее... Теперь смотри, допустим в каждую таблицу мы вводим дополнительное поле типа ID_CAT. Тем самым мы получаем постоянное количество таблиц, а значит всегда знаем где и что искать.. При этом используя фильтр по ID_CAT всегда в состоянии выбрать нужное.

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

    При этом независимость каталогов абсолютно сохраняется на все 100%. На мой взглят, не правильно пладить таблицы при увеличении контента.. У меня есть проект (J1.3) где порядка 10 разделов, в каждом из которых от 6 до 15 категорий.. Только представь объём таблиц. И как создавать запросы при твоём подходе.

    Что скажешь? ;) Давай порассуждаем вместе за плюсы и минусы



  • ArkadiyArkadiy Декабрь 2011
    1. Никто не мешает делать все типы контента в одном каталоге.
    2. например существует таблица с 10 000 записями, или 10 таблиц с 1000 записями - какая быстрее обработается?
  • GoDrGoDr Декабрь 2011
    конечно первый вариант (!) :)
    напиши запрос одновременно хотя бы к 20 каталогам для получения допустим 10 случайных записей ;) Ну и как будет выглядеть запрос?

    Я понимаю что можно всё делать и в одной категории, но если их несколько, то по сути получается это разные расширения (компоненты), как не назови, хотя имеющие одинаковую структуру

  • ArkadiyArkadiy Декабрь 2011
    Так именно что разные расширения, зачем и как ты собираешься использовать их все сразу? Никто и нигде так не делает (при использовании обычных компонентов), если модуль новостной, то он должен брать информацию из новостного каталога, если модуль галерейный, то из галереейного. Нельзя объять необъятное.
  • ArkadiyArkadiy Декабрь 2011
    Если все-же хочется сделать модуль который выводит контент из всех каталогов, то можно примениять его к текущему каталогу, а если каталог не объявлен, то брать контент из каталога, назначенного для главной страницы.
  • GoDrGoDr Декабрь 2011
    Можно :-D
    Сама идея объять необъятное возникла при моделировании моего модуля "Главных новостей" и глобального поиска по сайту на Ajax... Если бы это было в одной таблице, то значительно бы упростило бы задачу.. Ну или если бы модули имели возможность настраиваться как компоненты а не только через xml, т.е. иметь возможность выполнять PHP код и делать SQL-запросы
    Отредактированно GoDr в 2011-12-05 23:46:00
  • ArkadiyArkadiy Декабрь 2011
    ну твой модуль обслуживает только ком-контент, это равняется одному каталогу, а поиск по сайту на аякс - есть мамбот поиска по каталогам босса, его надо впрягать, либо делать по аналогии.
  • GoDrGoDr Декабрь 2011
    в том то и дело, что модуль обслуживает ком-контент, ну или один каталог.. А так как при настройке модуля нельзя выполнить ни запросы к базе ни PHP, то придётся "ручками" вводить из какого каталога и что именно брать.. НА сколько я уже полистал таблицы, то придётся задавать ещё и какие типы полей1 обрабатывать. Если существующие поля относительно стабильны (я имею ввиду что не будут меняться из версии к версии) то с этим проблем не должно быть. А вот из-за того что таблиц ровно столько сколько и каталогов, модуль пока не получается универсальным и для 1.3 и для 1.4, настройки абсолютно разные, а манипулировать ими при сегодняшнем механизме не реально..


  • ArkadiyArkadiy Декабрь 2011
    В том-то и дело, что стабильны только системные поля, поля контента могут быть совершенно разными от каталога к каталогу.
  • GoDrGoDr Декабрь 2011
    это не проблема. уже разработал как с этим бороться :) Я про то что надеюсь название и их предназначение не будет меняться.. Вот допустим сейчас создаётся каталог при инсталляции, там есть поля, и что они останутся в будущем :)
  • ArkadiyArkadiy Декабрь 2011
    Да, но при создании полей в каталоге будут прибавляться поля в таблице контента с неизвестными для нас названиями.

Добро пожаловать!

Похоже, что Вы здесь впервые. Если хотите поучаствовать, нажмите на одну из этих кнопок!

Войти Зарегистрироваться

В теме отметились

  • Arkadiy Декабрь 2011
  • fade Декабрь 2011
  • GoDr Декабрь 2011