анализе событий давно минувших дней
А есть тут те, кто так же афигенно шарит за проектирование архитектуры данных, в частности mysql/mongo?
Переквалифицировались. Ох и слово 20 лiтер.
Вы лучше вопрос задавайте, приятнее отвечать по делу, если получается. Круто же, когда тригерит технический вопрос, а не "ешьте говно лопатой" ) ЗЫ я не шарю в "геополитике", поэтому... да, есть такие )
Вопрос следующий, мне интересно, как сделать аналог тех же гугл таблиц. А именно, как и где лучше хранить данные. Может быть динамическое количество ячеек от A до ZZ и количество строк, на сколько я знаю, свободно может достигать нескольких миллионов. Сложность в том, что так же нужна возможность поиска значения строки по произвольному столбцу. Что-то вроде "найти строку, в которой столбец Y содержит..." Я вижу тут два варианта, mysql с двумя таблицами страница_таблицы (ид, имя) ячейка_таблицы (ид, страница_таблицы_ид, имя ячейки, значение) При чем, как я понимаю, значение должно быть индексом, чтобы искать по "содержит", имя ячейки должно быть индексом, чтобы была возможность "вынуть" все значения по строке, а ещё должен быть уникальный составной индекс страница_таблицы ид_имя ячейки - в итоге вся таблица в индексах О_О С монго у меня не много опыта, рассматривал так же вариант хранить json-документ в формате (имя_ячейки:значение) - но тут как я понимаю две проблемы, нет возможности получить "соседние" ячейки, и при изменении хотя-бы одного значения в таблице нужно перезаписать весь документ. А большой документ может и под 2мб весить.
Правильно думаешь. По mysql почитай повнимательней, чуть больше знаний тебе надо. Поиск через like например. Там текстовый есть поиск. В целом, хранить можно где угодно. В целом, непонятно зачем тебе это. Ищи готовые оешения
Не предполагаю где можно найти подобное готовое решение. Про лайк я конечно знаю. В варианте с mysql меня очень напрягает, что вся таблица в итоге становится индексной
Обсуждают сегодня