3) возможно есть что-то для больших файлов у c++.
- суть разбора больших файлов (1, 10, 100, 1000 гигабайт на файл и больше) в том что бы читать его чанками по несколько байт (размер выбирается исходя из задачи) и анализ файла в поточном виде (не загружать его весь в память)...
exxagw: написал пример в ответе. В кратце вот что не хватает вашему варианту:
1. когда используется несколько таблиц для однозначного определения к какой таблице относится колонка используется запись table.column
2. user_id от messages является вычисляемым, а в ON можно использовать только колонки, либо "вычислять" повторно опять таки в ON, я это сделал через условие аналогичное выборке. ON (u.user_id = m.from_id OR u.user_id = m.to_id)
Так же можно сохранить первую выборку во временную таблицу и сделать LEFT JOIN по ней.
Если LEFT JOIN не желателен то временную таблицу можно обновить через INNER JOIN пропуская те строчки где соответствий нету и забрать готовые данные уже из временной таблицы.
Сделайте LEFT JOIN отдельным запросом, что бы не гонять кучу дублей (если подставить LEFT JOIN в выше-описанный вариант то будет вначале выборка, а потом GROUP BY)
Впрочем, можно сделать вложенный SELECT, почитайте тут: www.mysql.ru/docs/man/ANSI_diff_Sub-selects.html
AtomKrieg: человек учится, сейчас у него такая ситуация, а завтра другая. В общем увидел в совете антипаттерн который не плохо было бы дополнить вариантом когда в память не помещается.
Впрочем, следуя вашему алгоритму пользователю нужно от 1 до 2 гигабайт оперативной памяти для хранения:
- всего файла целиком
- результирующего массива
И этот вариант медленный, к тому же даже гигабайт на такую задачу - расточительство. Исключительно личное мнение, не более.
По умолчанию в таком запросе название колонки будет взято из первого запроса (конкретно тут название будет from_id).
Некоторых это может поставить в тупик. По этому предпочтительнее указывать название через as:
SELECT from_id as user_id FROM table WHERE to_id = 5
UNION
SELECT to_id as user_id FROM table WHERE from_id = 5
Борис Животное: буду признателен если напишите и поделитесь опытом такой вот крос-платформенной работы. С графиками и бенчмарками сравнения. Иными словами - хочу понять что именно привлекает вас писать под Linux на C# к примеру. Хочу понять в чём профит.
Ладно браузер, а что будете делать с node.js и проблемами которые возникнут при его использовании? Сможете поддерживать код самого node.js без проблем?:) Вот где дебаг просто "весёлое" занятие:)
Исключительно имхо, но C# тебя будет ограничивать одной платформой (Windows), конечно сейчас Windows 10 и экосистема Microsoft хороша, но есть шанс в ней застрять. Рассчитывай на то что при обучении в C# и в экосистеме Microsoft ты получаешь только одно мнение с одного ракурса и на общее программирование этого мало.
В таком теоретическом ключе не возможно предложить оптимального варианта. Думайте сами. А то кажется что вы франкинштейна делаете, хотя может быть это и не так.
Или про что-то ещё?