Непонятно при чем здесь .idb? Это кажется Intermediate Debug File. Какое это имеет отношение к MySQL непонятно.
Непонятно что хочет автор? Программировать БД через язык C# - это одна задача. Перво-наперво надо качнуть драйвер (какой нить MySQL connector for DotNet) и начать писать код.
И другая задача - это просто получить консоль SQL к этой БД. Для этого обычно качают MySQL client. У него в составе есть mysql.exe и там - то что доктор прописал.
Полностью поддержваю соменния насчет диска. При 5000 соединениях во первых канал будет поделен на 5 тыщ в пропорции. Если не поделен - то тогда зачем им вообще параллельно работать верно? Тоесть мы должны заложиться на какую-то сверх-быструю дисковую систему и такую-же быструю сеть.
Возможно-ли кластеризовать или партиционировать самих клиентов и их хранилища? Это был-бы инженерный вариант решения проблемы.
Кроме того они р-синкаются когда им вздумается. Следовательно сутошного баланса нету. В 19-00 - 20-00 в час наибольшей нагрузке все ломануться в одно время и будет затык. Возможно имеет смысл придумать расписание. Скедулер. И рекомендуемое время р-синка. Ну тоесть не запрещать а рекомендовать.
Тут Брезенхем не подходит потому-что кнопка должна двигаться хотя-б с постоянной угловой скоростью. Брезенхем конечно шикарно быстро рисует одну восьмушку окружности но он не обеспечивает этого постоянства. Со стороны тогда движение кнопки будет выглядеть неестественно.
imageman, я думаю что таких будет большинство. Это собсно главное преимущество PNG над GIF например. Полу-прозрачные альфа-каналы. Gif - поддерживает только однобитные.
Я думаю что баг разработки. Разработчик действительно закинул в меню неоптимизированную графику. А сектор тестирования мало уделял время тестированию самого меню.
Да и кому надо это меню? Люди 99% времени сидят в игре а не в меню.
Да согласен. Пусть греется. Майнеры в общей массе сейчас жгут электичества как Норвегия. Кого интересует меню одной игры?
davidMSK, воот. Int - это двоичная система. Значит надо делить на 10 и вычислять остаток от деления на 10 пока число не опустеет. Рекуррентное правило. Ну и попутно смотреть что в остатке от деления - лежит десятичный знак больше или меньше предыдущего.
Задача мне видится не сложной. Просто не промахнуться с первым ходом. Для него должен быть отдельный if condition.
Ну ты автору написал банальности. Типа Волга впадает в Каспийское море. Ты ему расскажи как ошибку обработать. Может у него конфликт ключей лезет а он не видит.
Что такое "теги == токены" я не понял совсем.
"текстовый поиск" - это, как я понимаю, полнотекстовый поиск
Да. Тестовый поиск (обычно) ищет по текстовым индексам из токенов. В грубом приближении
это очищенное представление документа. Как-то сведение всех слов к основе. Стемминг. Лемматизация.
Убирание всяких предлогов и шумящих символов. В данной задаче например тело поста после
такой обработки мало чем будет отличаться от тегов этого-же поста. Вот поэтому я и предложил
соединить пост и теги в один datarow.
Затем через джойн, по первичному ключу, точно так же мгновенно находятся нужные посты
Я-бы хотел уйти от джойна в данной задаче. Я по сути материализовал ваш join и теперь мне его
делать не нужно. Ведь алгоритмы текстового поиска найдут все мои теги так-же точно как и соединение.
Моя идея будет более понятна если представить что и пост и теги у нас лежат в Postgresql в поле
типа JSON.
Вопрос нормализации я предлагаю оставить пока за кадром. Ведь мы обсуждаем соц-сети
где исходные данные всегда денормализованы и поэтому нам не стоит бепокоиться о том
что не было гарантировано изначально.
Вообще здесь нормализаций это некий фетишь который мы конечно можем реализовать для
себя лишь на 5 минут и затем поняв что она не нужа - снова денормализуем для текстового поиска.
Непонятно что хочет автор? Программировать БД через язык C# - это одна задача. Перво-наперво надо качнуть драйвер (какой нить MySQL connector for DotNet) и начать писать код.
И другая задача - это просто получить консоль SQL к этой БД. Для этого обычно качают MySQL client. У него в составе есть mysql.exe и там - то что доктор прописал.