Сразу оговорюсь это раздел "Беседы", я не спрашиваю как сделать, я хочу начать беседу на тему "как было бы хорошо.." Еще оговорюсь, я новичок, да и не было у меня ни каких проектов, но все же какие то мелочи я делал для пополнения своей копилки знаний. И очень часто возникала такая проблема, сделаешь таблицу в БД начинаешь ее использовать и на стадии доработки проекта возникает необходимость к этой таблице добавить еще столбец, а потом еще, некоторые из этих столбцов будут использоваться один раз из десяти записей. Я работал с Wordpress и там такая система таблиц, там две таблицы допустим post и post_option, в post набор необходимых столбцов (id, title, content, autor, date, уровень доступа, пароль, статус), а все что надо будет добавить сверху идет во вторую таблицу, которая устроена по типу ассоциативного массива key - value (id, post_id, key, value) - очень удобно, но все же это 2 таблицы. Было бы прикольно если бы разработчики MySQL сделали такую штуку, столбец в котором элементы выглядели бы как таблица по типу key - value, на примере PHP это выглядело бы так: Код (PHP): class page { public $id = '1', $title = 'str', $content = 'str', $status = 'str', $date = '10.10.1010', $others = array( 'key1' => 'value1', 'key2' => 'value2' ); } Я к чему клоню, если кто то считает так же как я и знает английский, может черкнет в MySQL письмо, пусть сделают такое
Чуго? Добавлено спустя 2 минуты 13 секунд: А, таблица в таблице. Зачем тебе? Если выборок нету - сериализуй и пиши. Если выборки по этим полям будут то отдельная и индексы
таблица в таблице это образно говоря, просто такой формат хранения данных, где непосредственно в ячейке будут храниться данные по типу таблицы из 2-х ячеек key - value Зачем? допустим в том же Wordpress когда надо добавить сообщение (данные в таблицу post) и потом дополнительные поля (значения) в таблицу post_option это 2 запроса, а тут все в один укладывается. да и еще, это называется в Wordpress не post_option, а post_meta. PS зачем переместили тему, это не вопрос, я и так знаю что такое не возможно (не реализовано).
потому что там не webdev беседы, а тут вполне себе околоwebdev фантазии. чем сериализация не угодила, раз выборок не планируешь по этим полям?
выборка планируется. Да и если у меня будет 10 значений, а надо будет поменять одно, получается мне надо будет получать весь объект (все 10 значений) одно изменять и потом вставлять весь объект обратно. по-этому сериализация или XML не катит. Это будет костыли, а не решение.
ну так если бы реализовали разработчики MySQL таблицу в таблицы, так как описано выше, было бы лучше, всего один запрос, не 2 как допустим в wordpress. Может напишите им письмо?
эмм.. я точно не знаю как там работает БД но на сколько мне известно индексы можно включить, а можно и нет, например: Код (Text): CREATE TABLE cms_option ( option_id BIGINT(20) unsigned NOT NULL auto_increment primary key, option_name VARCHAR(1024) NOT NULL, option_value VARCHAR(1024) NOT NULL, INDEX(option_name) )' на option_name индексы включены, а на option_value уже нет, так же сделать данный тип столбца (ну там где таблица в таблице) что бы там вообще не возможно было использовать индексы вот и все (обойдутся) ну или микроиндексы. В конце концов что то придумают. Пиши письмо в MySQL пусть приступают
Индекс строится по значениям столбца. Если у тебя в каждой ячейке своя структура, то придется делать в каждую ячейку отдельный микроиндекс. При чем ты не сможешь выбирать по индексам не указав конкретную запись и столбец.
Если будут микроиндексы, то какой в них смысл, если чтобы их использовать надо как минимум знать эту строку и это поле, а хочешь ты просто какие-то параметры сохранять. Смотри https://www.google.ru/#newwindow=1&q=postgresql+json
Интересно бы было поднять тему. Скажем так, у меня есть информация, которую после действий пользователя нужно анализировать. Как впихнуть это в таблицу, не понимаю, так как количество столбцов будет всегда разное. Держать таблицу на 1000 столбцов и заполнять неиспользованные ячейки NULL? А если, в одну ячейку, запихнуть таблицу, скажем в формате XML?
Извините, профан во всем, что выходит за MySQL или еще хуже Access SQL. Где можно почитать? А самое главное, работает ли это все в связке с PHP? --- Добавлено --- Я интуитивно понимаю, что мое предложение не лучшее. Хорошо, я в MySQL впихну таблицу в формате XML, но обрабатывать эту фигню реально будет трудно.
почитай про NoSQL базы данных. С php нормально работают. Но почитать\поучить придётся. --- Добавлено --- https://www.php.net/manual/ru/mongodb.tutorial.library.php https://habr.com/ru/post/103699/ не ленись гуглить.
для начала не помешает умение сомневаться в выбранном решении ))) выбор неструктурированного хранилища может быть признаком плохого проектирования. в общем случае не зная контекста сложно что-то советовать, просто для подавляющего большинства применений реляционные базы подходят очень хорошо, если их правильно готовить. то что в ноде так любят монго, говорит не о п*здатости монго (хотя он п*здат по своему), а о том, что люди из мира фронтенда не научены мыслить строгими категориями. и тащат своё г* в новую область. --- Добавлено --- эх, надо было начать так: не очень страшно если часть полей будет содержать NULL. и кто решил, что это должна быть строго одна таблица? TL;DR; ...