> InstantCMS позволяет создавать закрытые разделы по подписке
По ссылке на Биллинг есть видеообзор возможностей, посмотрите. Насчёт целых разделов (категорий, etc) не уверен, но поля типов контента точно можно продавать/продавать подписку.
В любом случае автору Биллинга можно задать вопрос, за который, как известно, денег не берут.
Тогда можно this.data отправлять как строку в каком-нибудь параметре POST, а не телом POST запроса
$.post('/apiw/', {param_name: this.data});
Тогда в $_POST['param_name'] будет ваша строка, которую вы прогоните через json_decode.
Но в целом, вполне можно в данном случае получать и через php://input как ответили выше. Вопрос в удобстве.
> А новые записи в эту таблицу добавлять на этапе добавления записей в остальные
Да. Добавили запись в одну из основных таблиц - добавили запись в agregate.
> На стороне php проверять из какой таблицы конкретная запись, стОит по какому-то полю, которое есть в одной таблице но нет в другой? Вроде if(is_null($row['one_id'])) // значит это вторая таблица
Это уже какая у вас итоговая задача, например, разные шаблоны вывода для разных записей. Тут уже как вам удобнее/необходимо.
Также, можно выбирать записи только из таблицы agregate (без джойнов) - формировать список id записей. А после в два запроса выбрать по списку id из двух таблиц через IN (id1, id2, ...). По производительности, при наличии индексов в таблицах, не проиграете.
Незачем из неё выбирать, она нужна только для связей. В select пишите то, что хотите выбрать из ваших таблиц. В случае совпадения названий полей позаботьтесь о префиксах.
SELECT one.*, two.field_name as two_field_name
FROM agregate i
INNER JOIN one_table as one ON one.id = i.target_id AND i.target = 'one_table'
INNER JOIN two_table as two ON two.id = i.target_id AND i.target = 'two_table'
one_table и two_table - это те самые ваши таблицы. Ну и я предположил, что в ваших таблицах есть уникальные поля id с авто инкрементом например. Для простоты выбираем из первой таблицы все ячейки SELECT one.* с их оригинальными названиями. Со второй таблицы придётся перечислить поля для выборки, назначив им алиасы, если такие названия полей есть в первой таблице.
> как такой запрос изменится, ведь бывает что нет региона, например просто город Москва и сразу родитель Россия.
Использовать вместо INNER JOIN - LEFT JOIN и в присоединении таблицы стран использовать поле i.country_id.
> как работает например База ФИАС которая хранит данные в плоть до улиц, там как раз все типы с родителями и детьми в одной таблице, а названия в другой.
К сожалению, не в курсе. Но вероятно да, использовать в таком случае вложенные множества, как ответили ниже.
> Так и получится например, найдено совпадений 20, у каждого название + район + область + страна + тип это уже 100 запросов.
Один запрос. Таблицы можно связывать.
SELECT i.*, r.id as region_id, c.id as country_id, r.name as region_name, c.name as country_name
FROM geo_cities i
INNER JOIN geo_regions as r ON r.id = i.region_id
INNER JOIN geo_countries as c ON c.id = r.country_id
WHERE i.name` LIKE 'Моск%'
> Почему вы считаете, что нужно хранить каждый тип в отдельной таблице
Для удобной выборки и для того, чтобы не делать так, как вы предложили в вопросе.
chelkaz: так какая проблема, можно и не поочерёдный выбор, смысл не меняется. Ищите город - в таблице с городами через LIKE находите, присоединяете связи с другими таблицами - это один запрос, учитывая наличие индексов - очень быстрый. Ищите область - тоже самое и так далее. Главное то, что все смысловые объекты должны быть в разных таблицах.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
По ссылке на Биллинг есть видеообзор возможностей, посмотрите. Насчёт целых разделов (категорий, etc) не уверен, но поля типов контента точно можно продавать/продавать подписку.
В любом случае автору Биллинга можно задать вопрос, за который, как известно, денег не берут.