— Ах, Delphi, сколько синих экранов, я с тобой повидал.
— Как много умений и знаний я с тобой нахватал.
— Я помню это, будто это было вчера.
— Работу с тобой, не забыть ни когда!

*и потекла, скупая, мужская слеза.

Макаров Александр
программист (большей частью «веб»)
прикладное программирование (иногда)
немного верстка, js и всего понемногу…
профессионально с 2007
vshtate.ru/id802482

Различные форматы ввода, вывода — что-то я немного упустил.
Нужно будет сделать обработчик форматов входных, выходных данных.

Надо поднять проект (github, redmine) и расписать задачи.

SSL — вопрос, решающийся легко и быстро.
Различные форматы вывода — тоже не проблема (входящие форматы — тоже)
Самое главное — не одному этим заниматься. Так-то своих дел хватает, но хочется и этот проект продвинуть в сеть. Собрать-бы команду, 2-3 человека — было-бы веселее и быстрее пошло.

Есть еще проблемы с алгоритмом — на это нужен основной упор, сейчас сделать.

Я понял.
Твой случай:

I    K      V
1    author Кизяков
1    book   Кулинария
1    year   2005

Когда ты будешь делать запрос:

WHERE `book` = 'Кулинария'

учитывать — запрос сделан в формате SQL, в ODS запросы формируются массивом

array('book'=>'Кулинария')

значение `book` — будет индексировано, а значение 'Кулинария' — нет.
Довольно легко решается постановкой столбца V в индекс (FULLTEXT), но тогда мы получим очень большой индекс по полю V, что может плохо сказаться на производительности.
Ко всему прочему, используется InnoDB, он «у меня», не дружит с FULLTEXT

Согласен — это можно считать еще одним минусом

Индексы ставятся для столбцов (I,K)
где:

I — идентификатор объекта
K — поле объекта

так что, по сути все поля объекта индексируются.
Советую сделать небольшой тест:
Создать две таблицы (одну с индексами, другую — без), заполнить их данными (объектами), по 1000 (10000) объектов, где каждый объект по 10 полей, и сравнить скорость выборки, для каждой таблицы.
Разница есть, и даже ощутимая.

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

По поводу кириллицы — это просто был тест, на извращения. :)

ODS разрабатывается и используется для тех случаев, когда нужен MongoDB, но установить его не хостинге (VDS или сервере) нет возможности.
По своей сути (плохая, но все же) альтернатива MongoDB на основе MySQL.

По поводу EAV — соглашусь.
По поводу ключей-varchar — исходил из возможности использовать для ключей любые значения (даже кириллица допускается).
Индексы — да, сам не понимаю зачем… но проводил небольшие тесты, и вроде как ключи делают свою работу.
Не рациональное использование самих таблиц — это как посмотреть. С одной стороны — не рациональное использование, с другой — гибкая архитектура.

Да, именно вложенные объекты или просто сложные (многоуровневые) массивы.
Отсюда и решение продолжать развитие.