Собственно имею массу данных в виде php объектов сериализованных в файлы. (более миллиона штук, десятки самих объектов). Можно ли как-то средствами php либо сторонними небольшими библиотеками сериализовывать их в БД с минимальным объемом написанного кода ? (в идеале, конечно, даже тип полей по содержимому детектить, но это не обязательно). Разумеется не в виде таблиц с блобами, а с разборкой по полям. Так, чтобы из class Person { public $name; public $family; } Получилась таблица Person с столбцами Name - Family и соответствующим содержимым, можно было получить код для create table итд итп.
Именно. Как не занимаясь написанием кода для каждого класса сериализовать его в БД ? Может есть готовые библиотеки какие-то. Чтобы вызвать что-то типа SerializeToDB($dbname, $person) и получить строку в таблице person где в каждой ячейке одно из полей person Вопрос не стоит в том, как ВРУЧНУЮ написать инсерты итп. Это никому не нужно. Простая сериализация в текст ведь не требует от класса никаких дополнительных методов. Для DB такое как-нибудь реализованно ?
никак ладно я не знаю, как у вас там что сериализуется в текст. сериализация это общий термин, а не конкретный способ. но в общем случае объекты сами по себе в бд не запрыгивают с другой стороны, бд всё равно что заданные вы в неё пихаете и ещё, если вы сериализуете их в json, то можно пихать, и некоторые бд сами вам позволят обращаться с полями итогового json как с полями таблицы: строить индексы и делать выборки
Насколько я понял, ты хочешь функцию, которая сможет получать на входе имя таблицы и некий объект, записывать это в бд, используя свойства объекта в качестве полей таблицы, а значения свойств в качестве значений таблицы. Причем тут сериализация? Любой приличная библиотека для работы с бд умеет такое делать. Я сейчас пользуюсь либой для мускула. Вот бы как в ней выглядел вызов для того, что ты просишь. Код (Text): function todb(string $table, object $data){ global $db_conf; $db = new Simpledb($db_conf); return $db->query("INSERT INTO `$table` SET ?u", $data); } Достаточно компактно?
Обобщенно - да. Этот процесс так называется , и согласно википедии тоже Сериализация — это процесс преобразования объекта в поток байтов для сохранения или передачи в память, базу данных или файл. Впрочем не будем о терминах, это контрпродуктивно. Да, вполне. Можно ссылочку, а то сплошной амазон ищется с его saas db ? (+ какие-то старые непонятные форки) Умеет ли она как-то создавать сами таблицы ориентируясь на данные ? Я уже, в принципе "запилил свой велик", но не хотелось бы его поддерживать. В $data какие-то методы, переменные или что-то еще требуются ?
О, спасибо большое. Напилил тем временем что-то похожее, но более "велосипедно" конечно. Принцип в общем тот-же. Щаз подумаем, что адекватнее доделывать.
хех, я думал чуваку нужно множество разношерстных объектов преобразовать в БД, что бы оно само создало структуру, связи и прочее. А чувак ищет обертку над mysqli. хех
Да можно было-бы и связи сделать, но не требуется, объекты слишком разнородные и "плоские". Create table у меня делает, в 95% случаев можно по данным понять какие типы полей нужны.
20-50 вариантов. Может больше. Разнородные но группами. (тысячи-десятки тысяч -реже сотни в группе). Много данных. Пока попробовал просто в mysql загнать, вполне дышит. Потестирую еще. SQL удобен всё-таки возможностью постфактум ключей наделать и некоторые выборки делать по данным всех не перебирая. Но это все "исследовательский" проект, так что пока непонятно насколько реально будет именно синтаксисом sql обойтись.
Не пользовался никогда noSQL, но вы правы, наверное имеет смысл как-раз на этом примере и попробовать. А то всё руки не доходят. Буду рефакторить переделаю на монго.
не обязательно мускул и постгрес умеют тоже с json работать, почитай --- Добавлено --- если конечно это json, т.к. ты до сих пор хз зачем, но хранишь тайну алгоритма сериализации.
Вот с тем брать мускул и постгрю или брать nosql, тут тебе нужно, как указал Игорь, не торопиться и внимательно подумать (протестировать) все операции с данными которые предполагается делать. Где-то в выигрыше окажется nosql, где то вполне может хватить реляционной субд. При правильной реализации через orm обычно рефакторить ничего не нужно, только на уровне коннектора к базе