Станислав Макаров

recurring_events или regular_events.

Сосредоточтесь на том, что это повторяющиеся события, а не цикл.

А мне нужен способ если я уже прошел регистрацию и потом отдельно дописать что-то в поле product.

UPDATE

Т. е. обратиться к определенной записи в БД, и взять текст определенного поля...

SELECT

Почитайте книги что-ли.

(Бд через RedBean организована)

Что говорит документация к используемому вами инструменту?

sqlfiddle.com/#!17/12350/11/0

select val from
(
    (select val from foo where val < 9 order by val desc limit 5)
    union
    (select val from foo where val >= 9 order by val asc)
) results
order by val asc

https://dev.mysql.com/doc/refman/5.7/en/views.html

MySQL supports views, including updatable views. Views are stored queries that when invoked produce a result set. A view acts as a virtual table.

Вообще гуглите про представления (views) и в частности про материализованные представления (materialized views), это боольшая тема про зависимые таблицы и их согласования.

The process of setting up a materialized view is sometimes called materialization. This is a form of caching the results of a query, similar to memoization of the value of a function in functional languages, and it is sometimes described as a form of precomputation. As with other forms of precomputation, database users typically use materialized views for performance reasons, i.e. as a form of optimization.

Если нет необходимости в множественных коннектах к БД, то SQLite - самое простое решение.

При миллионе записей 1 секунда на подсчёт количества??

Да у вас вообще индексы есть на эту таблицу и колонку id?

О каких аппаратных ресурсах может идти речь, научитесь СУБД пользоваться.

Есть простая таблица notes для мини-блога: id_author, header, text. И мне нужно найти вторые пять записей пользователя

В реляционной БД таблица - она же отношение (relation) - это множество записей, а не список. Т.е. они не упорядочены, и если сейчас вам запрос на выборку выдаёт их в одном порядке, то завтра он будет это делать в другом порядке. В записи нигде не хранится время её добавления, поэтому СУБД может перекладывать их как пожелает.
Чтобы решить это проблему, вам нужно добавить поле для хранения порядка записей. Проще всего добавить время публикации. Также вам, возможно, пригодится поле id или number для хранения номера самой записи, т.к. сейчас непонятно, может ли быть несколько записей от одного автора или нет (в теории - может, но непонятно тогда как вы их различаете. По заголовку?).
Затем вам возможно пригодится индекс (id_author, postdatetime), чтобы выборки с сортировкой по времени были эффективными.
Теперь вы сможете выбрать:

select header, text from notes where id_author = <автор> order by postdatetime limit 5, 5

При этом "узким горлышком" производительности веб приложений как правило является именно БД.

Логично, ведь большинство веб-приложений это выборка с некоторой простой обработкой. А БД не все умеют хорошо спроектировать.

Имеет ли смысл сортировать и группировать результаты выборки с помощью ЯП, чтобы убрать сортировку и группировку из запросов?

Это имеет смысл только если у вас вообще нет индексов, и по каким-то непостижимым причинам вы не можете их добавить. Чтобы отсортировать быстрее СУБД, нужно построить индекс самому, а вы вряд ли сделаете это лучше СУБД, еще и так, чтобы покрыть расходы на передачу данных. Группировку имеет смысл только если агрегирующая функция вычислительно очень сложная, но такое вы скорее всего в SQL запросе писать и не будете.

Даже если у вас sort и group действительно занимают основной процент времени, перенос этих операций в код приложения врядли вам поможет. Иначе говоря, пока вы добьетесь приемлемого результата от такого решения, вы добрую часть алгоритмов СУБД перепишите заново (сначала вы напишите индексы для поиска или сортировку слиянием, потом, как заметил Сергей Савостин у вас всё равно данные не будут влезать в ОЗУ и вы захотите писать их на диск, тут же вашу копию данных в приложении нужно будет синхронизировать и вы начнёте писать примитивную репликацию и так далее..)

Безусловно, БД проектируются так, чтобы лучше всего обрабатывать большое количество сущностей в малом количестве "контейнеров" - много записей в небольшом числе таблиц, много документов в небольшом числе коллекций и т.д.

5 миллионов и даже 100 миллионов записей для нормальной СУБД это вполне адекватная нагрузка (до 1 миллиона - это вообще ни о чём). Как уже заметил Петр , ГОРАЗДО важнее то, какие индексы вы добавите.

Схемы и таблицы должны добавляться исходя из нужд приложения, например при добавлении новых фич. Базы данных должны создаваться исходы из административных нужд - ограничение доступа, политика резервного копирования и т.д. 5, 10, и даже 50 БД на одном сервере это нормально (если на это есть основания), а вот 500 тысяч - это уже ни в какие ворота.

Ответ на вопрос зависит от архитектуры вашего приложения и его компонентов. Если у вас только тонкие клиенты, а бизнес-логика вся обернута в сервис и в ней реализован весь необходимый контроль доступа - то тогда отдельные пользователи не нужны (за исключением разве что отдельного пользователя для самого сервиса и отдельных - для административных целей, чтобы сервис максимально был ограничен в правах).

Если толстые клиенты тоже есть, т.е. такие, которые сами содержат бизнес-логику и напрямую пишут в базу, то тогда есть смысл разделять пользователей. Как правило, разделение идёт по ролям в приложении. Т.е. для всех бухгалтеров отдельный пользователь, для всех складовщиков - также. Это поможет ограничить множество допустимых действий с БД и уменьшить риски (которые по определению будут в случае толстых клиентов).

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

То, что вы сейчас делаете - это EAV (Entity–attribute–value), можете гуглить по этому термину. А вообще советую переместить параметры товаров в документную базу (ибо EAV это костыль).

возможно с ведущим нулём

Но это всё равно строка

вы сами ответили на свой вопрос.

char(12) charset latin1

Да, это хороший совет. Абсолютно бессмысленно и глупо использовать varchar для строк постоянной длины.

а искать по строкам я не люблю

А если перейти от личных предпочтений к реальным измерениям - действительно ли будут проблемы?