При правильной архитектуре и настройке индексы из памяти не вываливаются, поэтому как они хранятся на диске по фиг. К тому же непонятно, сначала Вы говорили что производительность из-за декомпрессии не падает, а теперь говорите что в сжатии/разжатии проблема.
Но в принципе согласны, что для г-но проектов при условии что на хостинг денег совсем нет и пара мегабайт имеет значение - вполне может пригодится. Тот же вордпресс зачастую проще ужать, чем делать по уму.
Заработать денег ничего не вкладывая и перенеся риски на клиентов.
Это сейчас поветрие такое ничем не рискуя и почти ничего не вкладывая - посредники рубят бабки - яндекс.такси, алиэкспресс, амазон, озон.инвест вот.
Спонсируй он заемщиков сам - и невозврат лег бы на него и кэш нужен был бы для кредитования. А так и риск только у кредиторов, а доход только у озона.
У него видимо странный таргетинг, мы его рекламу постоянно видим:)
Этот спич у нас проассоциировался исключительно с "куплю жене сапоги"© Расписывается офигительно выгодная схема, под нее подводится база, а потом... предлагается заключить договор по которому никаких реальных гарантий. Что Вам там про ИП и товары чешут это что-то одно, что будет в реальности происходить - Вы не узнаете, т.к. у Вас никаких данных не будет.
Так залог это не компенсация ущерба, а страховка от него. При долгосроке залога тоже ни на что не хватает так-то.
Да ну, гоните. На том же букинге и аирбнб достаточно квартир/апартов с залогами и ничего - заняты достаточно плотно.
Если структура правильная и вынесено, то можно сжимать всю таблицу, а не по колонкам, не теряя возможности индексации и других возможностей.
Чем это вдруг стало не подходить? https://dev.mysql.com/doc/refman/5.7/en/innodb-compression-usage.html без потери индексации, в этом вопрос.
LEOnidUKG,
Производительность все же меняется, бесплатного ничего не бывает. На хдд может даже вырасти, т.к. данных меньше считывать при большой таблице, а вот на ссд может упасть, т.к. декомпрессия все же проц грузит.
Невозможность индексов вкупе с нагрузкой на проц при поиске по всей таблице обессмысливает затею.
Если делать по правильному, то все поля которые компрессируешь - нужно выносить в отдельную таблицу, если они на фиг не нужны для работы с ними - фигли они место занимают там? Размер оставшейся рабочей таблицы уменьшится так, как не уменьшится даже при компрессии, при этом бонусом останется возможность индексации.
С трудом себе представляем сценарий когда при правильной архитектуре это может понадобится.
В основном из-за легкой тени ibm-ки, родные ленововские буки качеством чуть ниже среднего (на уровне асеров), но т.к. леново купило айбимку, то от них ожидаю идеального качества айбимовских финкпадов и естественно плюются.
Плюс леново испортило себе репу несколькими неудачными йогами - перегревались и тротлились адски, ломались на раз-два, к нормальным ноутам это отношения не имело, но тень на бренд легла.
Dram,
group_concat , учитывая что уже вроде 3 раз на него в похожих ситуациях Вам же отвечаем, расписывать не будем:)
Как из фразы "стоимость 4 часов работы в неделю" можно было сделать вывод о том, что это вместе с директом, бюджетом на ссылки, закупкой текстов и т.д.? Сколько всего получится не говорят, но платить предлагают самим напрямую.
