Станислав Макаров

Из самого torrent-файла - невозможно, возможно только попытаться реализовать частичное скачивание необходимых кусков (в зависимости от формата видеофайла) с метаинфой.

> мне нужно сделать так, что бы вставляло только в том случае, если для ключ2 не было дубликатов ключа1, а если ключ2 разные, то дубликаты ключа1 допускаются

делайте лучше одним запросом попытку найти комбинацию ключ1 и ключ2, вторым - добавление. Ну или можно положиться на constraint-ы, и просто сделать пару (ключ1, ключ2) нормальным первичным ключом - тогда мускул пошлет вас при попытке вставить второй такой же. Обратите внимание - ключом должна быть именно пара, а не два уникальных ключа по отдельности.

Я вот себе в закладки положил, и вам советую:

stackoverflow.com/questions/4048151/what-are-the-o...

Лучший известный мне список способов хранения иерархических данных в РСУБД.

Альтернативный LEFT JOIN-у вариант - оператор EXCEPT, который представляет собой операцию "минус" на множестве кортежей: en.wikipedia.org/wiki/Set_operations_%28SQL%29#EXC... . Т.е. вы выбираете все задания, и исключаете те, которые нужно... исключить:

select task.id from task
except select excluded_task.id from excluded_task
    where user_id = <id юзера>

Таблица excluded_task это пары (id, user_id) - если юзер исключил таск с некоторым id, в этом отношении будет соответствующий кортеж.

А какова цель использования хранимой процедуры только для получения данных? Я понимаю вы бы делали запросы на модификацию с добавлением логики, чтобы все это выполнить на стороне БД, а выборку-то зачем? Если есть конкретные причины, укажите, и подумаем как лучше сделать.

Пока в наших университетах (колледжах, техникумах, etc.) будут ставить такие задачи, из учебных заведений будут выходить малополезные специалисты, которые все будут учить заново на работе. Вместо того, чтобы давать студенту широкий взгляд на предмет и множество инструментов (в противоположность работе, которая не всегда может дать корректную и не предвзятую оценку используемым технологиям), университетская программа становится источником историй и анекдотов с участием неопытных специалистов и их боевых наставников (тимлидов, опытных коллег).
Вместо того, чтобы поставить задачу с архитектурным уклоном (вроде "напишите функцию-фабрику, создающую объект нужного класса и возвращающую экземпляр, обернутый в shared pointer"), чтобы продемонстрировать кейс применения умных указателей, студентам говорят "прикрутить". Неужели на специальностях машиностроения тоже говорят "прикрутить", а не соединить детали в работающее устройство?
Извините за оффтоп, очень уж классический пример.

Грамотно было бы разбить этот вопрос на несколько и указать для каждого необходимые детали, либо выбросить из него всю шелуху и оставить что-то одно.

Чтобы движение было плавным, нужно плавно анимировать это движение (т.е. перерисовывать положение и внешний вид объекта N раз в секунду).
Процесс взаимодействия между юнитами зависит от архитектуры вашей игры и ее целевого функционала. Если это сингл-плеер, то я думаю не всегда хорошо дожидаться конца анимации, чтобы рассчитать урон (например, для игрока вполне естественно обнаружить нанесение урона в момент когда его меч коснется противника, а не когда закончит движение). Если это сетевая игра, то у вас есть интересная и непростая задача компенсации пинга.
Если вам кажется, что я изображаю капитана Очевидность, то вам нужно задать более точные и конкретные вопросы.

Если планируется использовать дотнет (как для "процессов", так и для сайта), то имеет смысл использовать преимущества платформы. Я бы поступил следующим образом:
- на ASP.NET реализовать логику сайта + бизнес-логику; здесь же - постановку "заказов" в очередь контроллера;
- отдельный процесс операционной системы - контроллер (хост) для выполняющихся "процессов"; каждый такой контроллер (их может быть несколько) загружает в отдельный домены приложения (application domain) сборку/сборки с кодом "процесса", настраивая ему права доступа к окружающей системе (песочницу); т.о., при постановки задачи в очередь конкретному контроллеру (выбирать можно рандомно или по загруженности), последний, при готовности, создает домен приложения, грузит в него нужную сборку-плагин, и запускает код на выполнение с нужными параметрами.
- код "процессов" оформлять в виде дотнетовских сборок; оформить интерфейс, который будет реализован каждой сборкой;
- прогресс можно конечно писать в БД, но можно и не писать: правильно работающий контроллер может и сам докладывать о состоянии выполнения наиболее актуальные сведения; в тот же интерфейс, через который контроллеру отдаются в очередь задачи, можно добавить и возможность запроса состояния выполнения; на клиенте брать по ajax, только конечно не в цикле, а по таймеру.
- в базу можно и нужно писать время старта/завершения задачи, результат (успех/ошибка) и т.д.;

такая архитектура позволит вам выделить отдельные машины для сайта, отдельные - для исполнения, наращивать количество контроллеров "процессов" и количество машин, обслуживающих сам сайт.

Эта фича называется CodeLens. Тут вот ваш вопрос один-в-один:
stackoverflow.com/questions/25380407/visual-studio...

Весьма глупо оценивать "говнокодерность" вашего подхода только потому, что вы храните массив в ненормализованном виде. Чтобы это увидеть, достаточно вспомнить само понятие нормализованных данных и подумать о его сути. Вот вам пример в лоб: вы же почему-то не говорите, что хранить строку в БД это плохо. А ее, в теории, можно представить как массив символов и нормализовать так, что одна строка некоторой таблицы будет хрнить ОДИН символ. Чушь, скажете вы? Да, для большинства задач это чушь (хотя, возможно не для всех). Просто потому, что НИКОМУ не нужно извлекать из базы ЧАСТЬ строки, какое-либ подмножество ее символов. В большинстве задач строка берется как атомарное (!) значение и именно _поэтому_ ее никто не пытается хранить посимвольно. У нас есть лишь один полезный критерий - что для вашей задачи есть атомарные значения? Все. Если вы ваш массив всегда будуте записывать и извлекать сразу целиком, то и хранить его как единственное значение в поле одной записи - совершенно не проблема.
Почему-то все считают, что пока не нормализуешь "до чертиков", спроектированная база никуда не годится. Да, конечно нормализация важна, есть смысл даже нормализовать "с запасом", как уже сказали выше - на случай, если какие-то данные впоследствии также будут фильтроваться и обрабатываться на уровне БД с помощью SQL. Однако если вы четко осознаете, что в ближайшем будущем вы не собираетесь работать с массивом поэлементно (на уровне SQL), то хранить его целиком пойдет только пользу.
Все же юзают JSON и XML-типы данных в SQL базах, и ничего. И блобы юзают. Потому что если проектировщик знает, что планируется обрабатывать в запросах, а что - нет, то он знает и до какой степени нужно нормализовать данные.
trevoga_su привел великолепный пример с конфигом пользователя. Зачем пытаться его навороченную структуру (например, иерархическую) спроецировать на реляционную БД, если проще хранить его в естественном виде (JSON/XML/plaintext) и писать в БД целиком?
P.S. Массив кстати можно хранить не в текстовом виде, а в двоичном в BLOB-е, тогда и места займет меньше, и никаких вопросов с кодировками.

Можно попробовать абстрагироваться на уровне ORM, если таковой есть - т.е. объекты одних классов извлекаются через одно подключение к БД, другие - через другое. Если SQL-запросы пишете сами, то и думать нечего - структириуете код, как считаете естественным, и где-то в каком-то классе или контроллере (например, Logger) храните в поле необходимое подключение к БД. В другом модуле/классе - другое.

Не тратьте время (если конечно не для образовательных целей):
cpp-netlib.org

Отличный веб-клиент (веб-сервер кстати тоже есть). Интерфейс уже более-менее стабилен. Пример:
cpp-netlib.org/0.11.1/index.html#hello-world