— Ах, Delphi, сколько синих экранов, я с тобой повидал.
— Как много умений и знаний я с тобой нахватал.
— Я помню это, будто это было вчера.
— Работу с тобой, не забыть ни когда!
Макаров Александр
программист (большей частью «веб»)
прикладное программирование (иногда)
немного верстка, js и всего понемногу…
профессионально с 2007 vshtate.ru/id802482
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
так что, по сути все поля объекта индексируются.
Советую сделать небольшой тест:
Создать две таблицы (одну с индексами, другую — без), заполнить их данными (объектами), по 1000 (10000) объектов, где каждый объект по 10 полей, и сравнить скорость выборки, для каждой таблицы.
Разница есть, и даже ощутимая.
Да, из-за данных таблица будет «пухнуть» как на дрожжах, а вот ключи (при правильно использовании) будут «пухнуть» не больше, чем при обычной архитектуре.
Да и вроде как, БД и сделаны для того что бы хранить большой объем данных.
По поводу кириллицы — это просто был тест, на извращения. :)
ODS разрабатывается и используется для тех случаев, когда нужен MongoDB, но установить его не хостинге (VDS или сервере) нет возможности.
По своей сути (плохая, но все же) альтернатива MongoDB на основе MySQL.
По поводу EAV — соглашусь.
По поводу ключей-varchar — исходил из возможности использовать для ключей любые значения (даже кириллица допускается).
Индексы — да, сам не понимаю зачем… но проводил небольшие тесты, и вроде как ключи делают свою работу.
Не рациональное использование самих таблиц — это как посмотреть. С одной стороны — не рациональное использование, с другой — гибкая архитектура.
— Как много умений и знаний я с тобой нахватал.
— Я помню это, будто это было вчера.
— Работу с тобой, не забыть ни когда!
*и потекла, скупая, мужская слеза.
программист (большей частью «веб»)
прикладное программирование (иногда)
немного верстка, js и всего понемногу…
профессионально с 2007
vshtate.ru/id802482
Нужно будет сделать обработчик форматов входных, выходных данных.
Надо поднять проект (github, redmine) и расписать задачи.
Различные форматы вывода — тоже не проблема (входящие форматы — тоже)
Самое главное — не одному этим заниматься. Так-то своих дел хватает, но хочется и этот проект продвинуть в сеть. Собрать-бы команду, 2-3 человека — было-бы веселее и быстрее пошло.
Есть еще проблемы с алгоритмом — на это нужен основной упор, сейчас сделать.
Твой случай:
Когда ты будешь делать запрос: значение `book` — будет индексировано, а значение 'Кулинария' — нет.
Довольно легко решается постановкой столбца V в индекс (FULLTEXT), но тогда мы получим очень большой индекс по полю V, что может плохо сказаться на производительности.
Ко всему прочему, используется InnoDB, он «у меня», не дружит с FULLTEXT
Согласен — это можно считать еще одним минусом
где:
так что, по сути все поля объекта индексируются.
Советую сделать небольшой тест:
Создать две таблицы (одну с индексами, другую — без), заполнить их данными (объектами), по 1000 (10000) объектов, где каждый объект по 10 полей, и сравнить скорость выборки, для каждой таблицы.
Разница есть, и даже ощутимая.
Да и вроде как, БД и сделаны для того что бы хранить большой объем данных.
По поводу кириллицы — это просто был тест, на извращения. :)
ODS разрабатывается и используется для тех случаев, когда нужен MongoDB, но установить его не хостинге (VDS или сервере) нет возможности.
По своей сути (плохая, но все же) альтернатива MongoDB на основе MySQL.
По поводу ключей-varchar — исходил из возможности использовать для ключей любые значения (даже кириллица допускается).
Индексы — да, сам не понимаю зачем… но проводил небольшие тесты, и вроде как ключи делают свою работу.
Не рациональное использование самих таблиц — это как посмотреть. С одной стороны — не рациональное использование, с другой — гибкая архитектура.
Отсюда и решение продолжать развитие.