Структура БД

Добрый день! 

Есть идея написать свой компонент Книги, чтобы была возможность добавлять книги и главы. Вопрос, как лучше организовать БД, чтобы хранить данные? Есть пользователь, у него может быть много книг — это не проблема, эти данные можно записать в новую строку. А вот как быть с главами? Пользователь может добавлять, удалять главы — где и как их хранить? Новую таблицу создавать — не вариант, БД замусорится безбожно. Какие есть варианты.

Примерная схема данных: 

Автор     / Название книги / Текст     / Главы / 

Иванов   /  У моря              / Бла-бла / Глава 1, Глава 2 ...

Пысы:

Дополнения на  эту тему видел: одно платное, другое безплатное. Не то, чтобы жаль было 1500 р., я сам хочу для своей маленькой социсети написать простенький компонент, чтобы разобраться в кухне движка СМС. А безплатное дополнения Книги не  запускается в новой версии. 5 лет автор не обновлял.

Побывал на сайте АвторТудей — там красиво сделано, но мне такой не нужен, слишком громоздкий.

БД замусорится безбожно

странный аргумент. Лучше несколько хорошо декомпозированных таблиц, в каждой из которых хранится своя сущность, чем пытаться все разместить в одной таблице.

Книги храните в типе контента Книги. Для вывода глав напишите поле, скажем books. В базе сделайте таблицу под главы.

Пусть будет cms_books_parts с такой структурой

id|title|book_id|content

Использование типа контента для книг позволит использовать связанные с ним возможности: комментарии, поиск, подписки и др.

Документация по полям docs.instantcms.ru/dev/forms/field-file

Про контроллеры docs.instantcms.ru/dev/controllers

Для каждой книги создавать в БД таблицу?

 ruccich, для каждой книги создавайте запись в типе контента книги. А для глав этих книг хватит одной таблицы. Привязка к книге идет по полю book_id

 ruccich, вам надо сначала определиться, что будет у вас «минимальной единицей» — книга, глава или страница главы. Что из этого будет отображаться на экране пользователя. Это и будет ваша основная таблица. А далее к ней будут подключаться таблица с данными по главам, (если будет постраничный вывод), таблица с данными по книге, таблица с данными по по авторам. Потом если захотите, то привяжете таблицу с данными какие пользователи на какой главе/странице остановились и т. п.

 ruccich, для каждой книги создавайте запись в типе контента книги. А для глав этих книг хватит одной таблицы. Привязка к книге идет по полю book_id

То есть, структура записей будет такова:

Таблица book

book_id_1 / Иванов / У моря /

book_id_2 / Петров/ У речки /

Теперь для каждой книги нужно создать таблицу глав, вроде так:

Таблица book_id_1

Глава 1 / Глава 2 и т.д..

Таблица book_id_2

Глава 1 / Глава 2 и т.д..

Правильно я вас понял?

 ruccich, вам надо сначала определиться, что будет у вас «минимальной единицей» — книга, глава или страница главы. Что из этого будет отображаться на экране пользователя.

А если книг будет 500, то таблиц может быть и все 5 000, как это скажется на работе сайта?

Как работает БД InstantCMS? Посты записываются в одну таблицу, Статьи так же в одну, Новости так же в одну. То есть таблицы не плодятся. С Книгами так не получится видать. Здесь сложнее, одной таблицей не обойтись.

В безплатном компоненте Книги говорится, что книги хранятся в файлах на сервере, а не в БД. Насколько это лучше или хуже?

Вы видимо с базой данных никогда не работали, поэтому вариант с платным дополнением вам наверное лучше подойдет. 

Но если хотите знать, то как я писал выше вам надо определить «минимальную единицу». Например книгу можно разделить на тома/части. Тома/части можно разделить на главы. Главы можно разделить на страницы. Страницы можно поделить на параграфы )), но это в вашем случае уже точно лишнее. Поэтому у вас получатся такие таблицы:
1. Страницы всех глав всех книг
2. Главы всех книг
3. Тома/части всех книг
4. Книги
Плюс добавится таблица с авторами всех книг. Итого — максимум пять таблиц в базе данных будет. 

Опять же, если пользователь вашего сайта захочет почитать, то каки образом вы ему предоставите эту возможность? Как вы будете хранить книги? и т. п. вопросы вы не озвучили. Если книга это файл в формате pdf, doc, txt и т.п., которую можно скачать, то для этого достаточно создать поле для загрузки файлов в нужном типе контента. И ничего более не надо делать. Если вы делите книги только на главы и показываете читателю всю главу сразу на одной странице, то у вас будет всего три таблицы в БД:
1. Главы всех книг
2. Книги
Плюс добавится таблица с авторами всех книг.

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

В безплатном компоненте Книги говорится, что книги хранятся в файлах на сервере, а не в БД. Насколько это лучше или хуже?

Доступ к информации будет одинаковым, но хранение в базе позволяет структурировать данные и использовать эту структуру более удобно.

Есть у меня сайт книжный. Из личного опыта могу сказать, что хранить книги (много книг) в БД не очень хорошая идея. Лучше хранить в файлах.

Всё зависит именно от того в каком виде у вас сами книги. Если вы их печатаете прямо на сайте или «парсите» из файла, то тут лучше в базе хранить, а если вы отдаете читателю сам файл книги на просмотр, то тут хранить только в файлах остается. Но в случае с файлами вы не сможете заблокировать доступ к некоторым страницам книги или сделать платной 70% книги или главы и т. п.

Да, согласен. Всё зависит от задач. Как вариант книги в процессе написания, или ознакомительные фрагменты хранить в БД, а законченные произведения в файлах.

Я например файлы, в моем случае в формате .fb2 парсю прям на сервере в пхп, и отдаю распарсенный текст на прочтение. А распарсеный текст можно как угодно ограничивать хоть по страницам, хоть по процентам или ещё как нибудь.

1. Главы всех книг
2. Книги
Плюс добавится таблица с авторами всех книг.

С БД я работал, но не много. Начальное представление имею, потому и задаю вопросы, что начальное.

Смотрите, вот примерная структрура таблиц:

То есть, получается, если у второй книги 3 главы, а у первой 2, то у первой будут пустыми ячейки. А если автор назовёт свою главу не «Глава 1», а к примеру «Первая Глава. О волке», то вообще ничего не получается. Куда ставить новое название главы?

Хранить в базе плохая идея. Я работал с книжным сайтом как то. И хозяину пришлось переделывать логику когда стало много книг. Все книги следует хранить в файлах. А для всех манипуляций пишется компонент, который будет форматировать ваш файл в нужный вам формат для чтения на странице. Для этого есть специальные библиотеки, в которых можно задать разные параметры. В том числе сколько глав выводить и какие главы, обложку задать и тп. Так же вы сможете разрешить скачать файл после покупки и всё остальное. А всё что вы мутите с БД, это так, если только поиграться)

А всё что вы мутите с БД, это так, если только поиграться)

Спасибо. Ещё вопрос: как вы храните файлы? Вернее главы — в каждом отдельном файле, или в одном со специальным форматированием глав?

И да, я хочу сам разработать такой компонет, чтобы понять всю кухню движка.

То есть, получается, если у второй книги 3 главы, а у первой 2, то у первой будут пустыми ячейки. А если автор назовёт свою главу не «Глава 1», а к примеру «Первая Глава. О волке», то вообще ничего не получается. Куда ставить новое название главы?

Все записи в таблицах заполняются не слева на право, а сверху вниз. В этом случае не важно сколько глав будет в книгах, все главы будут в одной таблице и у каждой главы будет свой book_id. У глав одной книги этот book_id будет одинаковым.

З.Ы. Мое мнение, что файлы каждый раз парсить, дробить на главы и т.п. перед выдачей читателю, лишняя нагрузка на «железо» и лишнее время ожидания для читателя. Проще из базы вытянуть данные уже готовые к выдаче, чем вот это всё.

И хозяину пришлось переделывать логику когда стало много книг.

Да, бывает. Практика показала, что запросы к БД бывают разные. Их периодически надо оптимизировать, как сами запросы, так и саму структуру базы данных. Перед выходом 2.18.0 Fuze решал вопрос, как мне создать запись в одной из 16800+ категорий и при этом не повесить сайт наглухо. Старая версия cms обрабатывала запрос на пересчёт количества записей в категориях более 40 сек. Новая версия справилась менее, чем за 1 сек. Функционал остался прежний, но скорость обработки стала на несколько порядков выше, что в свою очередь снизило нагрузку на «железо». Тут всё очень сильно зависит от опыта разработчика.

Тут всё очень сильно зависит от опыта разработчика

Это да. Но в данном случае дело даже не в этом, имхо. Что бы было удобно работать с книгой, в любом случае придётся писать дополнительный функционал. Например, что бы продать книгу, нужно будет данные превратить в файл годный для чтения в читалке. Или просто выводить на страницу часть глав, как книгу тоже потребуется всё это дело оформлять. Конечно можно всё это делать и из запросов, но не думаю что удобнее и легче будет, чем чтение из файла подходящей библиотекой. Но это опять таки дело «вкуса»). Тот чел, который переделывал сайт, сотрудничал с сайтом литерс и они, как я понял, именно с файлами работают. Возможно это тоже сыграло роль в его выборе. Хз.