Dmitry Bay, пример со статистикой возможно не очень удачный, думал просто часто используемый. Попробую привести более реальный кейс.
Дают архивную таблицу myisam фирмы продающей 5 товаров, в 5 городов, 5 способов доставки и 5 способов оплаты. Все эти поля скажем varchar(25) и таблица с десятками-сотнями миллионов строк весит достаточно много. Задача оптимизировать размер таблицы без смены типа базы данных, скриптов с ней работающих, дополнительных таблиц - максимально быстро/дешево/безопасно. Загоняем все вышеозвученные поля в enum и таблица худеет в несколько раз. Но если мы хотим загнать в enum города/улицы доставки заказов упираемся в лимит 64 кб .frm файла. Ну и конечно минус enum предопределенные значения (для не архивных таблиц). Есть решение по уменьшению размера без дополнительных таблиц? Скорость выборки абсолютно не важна.
Dmitry Bay, Вероятно на любой вопрос здесь можно ответить "читайте больше литературы"? Зачем тогда этот сайт? Мне кажется чтобы каждый раз не изобретать велосипед.
1. Про вынос во внешние таблицы я знаю и сказал об этом, но если ТЗ оптимизировать данные без дополнительных таблиц (даже несколько обоснованное) буду делать так.
2. Нужно перекидывать базы между несколькими машинами, myisam тупо копируются файлы таблицы, с innodb это возможно? И это только один из кейсов.
3. Про индексы на enum поля я не спрашивал, интересует использования индекса подобно enum для хранения данных.
Информации в сети море, вопрос в ее актуальности. Например относительно недавнее появление в MySQL поля JSON позволило, в некоторых случаях, кардинально пересмотреть структуру баз и работу с ними.
Таблица "статистика посещений" приведена для примера на самом деле там поля не разрешения/ip а varchar(255) с соответствующим размером данных. Интересует общий подход. Статьи по организации хранения/скорости работы myisam/innodb я читал, но некоторая информация 3-5 летней давности вероятно не так актуальна сейчас.
1. Enum - с помощью него я уменьшал таблицы раз в 10, причем например архивные в которые данные уже не добавляются, да и чтение происходит несколько раз в год. Ерунда?
2. У myisam есть (были) свои преимущества, но некоторые, как понимаю, в данный момент не так актуальны. Например раньше myisam была существенно быстрее innodb на чтение, но сейчас вроде innodb существенно сократила отставание.
3. Про индексы я спросил так как слышал что данные можно хранить только в индексах (innodb?) и это получается по сути безлимитный enum без предопределенных значений. Вот этот вопрос меня особо интересует.
Ну еще вот описывается решение с встроенными функциями https://stackoverflow.com/questions/5643263/loadin... но я на практике его не использовал. Но я порой не очень доверяю таким API - сталкивался с тем что со временем они меняются, по мне тру JS или JQuery надежнее.
Ок, может опять чуть не правильно понял, но попробую. Последнее время больше сталкиваюсь с JQuery, приведу на его примере, но думаю все можно реализовать и на чистом JS. Короче подключается в extension JQuery, создаются два файла script.js и template.html и скажем последний загружается в скрипт методом типа .load() и вставляется в сайт innerHTML. Вот запамятовал будут ли работать скрипты (обработчики?!) из файла template, но обработчики можно оставить в файле script.js и обращаться к элементам шаблона и назначать им события по их id/классам/именам тэгов. Ну и еще вариант собирать дополнительное меню из json ajax'ом.
А если Google Drive использовать через API, либо через отправку на email? Можно будет еще и расшаривать логи разным пользователям и посылать уведомления (в том числе СМС). А если еще писать логи таблицами то можно работать с ними всякими формулами, делать графики и т.п.
Дают архивную таблицу myisam фирмы продающей 5 товаров, в 5 городов, 5 способов доставки и 5 способов оплаты. Все эти поля скажем varchar(25) и таблица с десятками-сотнями миллионов строк весит достаточно много. Задача оптимизировать размер таблицы без смены типа базы данных, скриптов с ней работающих, дополнительных таблиц - максимально быстро/дешево/безопасно. Загоняем все вышеозвученные поля в enum и таблица худеет в несколько раз. Но если мы хотим загнать в enum города/улицы доставки заказов упираемся в лимит 64 кб .frm файла. Ну и конечно минус enum предопределенные значения (для не архивных таблиц). Есть решение по уменьшению размера без дополнительных таблиц? Скорость выборки абсолютно не важна.