Когда технически не грамотные люди ставят технические ограничения это что-то странное.
Чтобы запустить dtsx пакет не надо быть администратором. Сделайте на локальном sql сервере и дайте им готовый пакет. Я не понимаю в чем проблема «запустить скрипт» и «запустить скрипт рядом с которым лежит еще dtsx файл». У вас есть ограничение на количество файлов чтоли? или что?
Если вам принципиально по программировать, то в данной ситуации я посоветовал бы вам написать на .NET утилиту, которая будет это делать. Открыли два конекшена, из одного читаете, в другой пишите, на все про все 15 минут работы. Встроенные классы для работы с Sql сервер там есть, с аксесом тоже, ну или ODBC, не полезут же они внутрь сборки смотреть, что у вас там.
У меня стоит дешевый Realtek-Based плеер, он читает все форматы, которые я пытаюсь смотреть. С mkv проблем нет. Телевизоры наверное, не все mkv прочитают.
Ну по USB 2.0 вы full hd видео не протолкнете, мне кажется. Да и вообще, по wifi потоковое full hd видео может быть проблематично передать. Надо посмотреть сколько получится битрейт, и замерить реальную скорость WiFi между точками. У меня, в разных комнатах скорость скачет от 80 до 120Mb\sec. Это при том, что приемник и передатчик поддерживают 802.11n и имеют три антенны.
Вам решать, но все таки присмотритесь к узким корпусам. У меня сейчас стоит корпус шириной 15см и он прекрасно встает за вечно открытую дверь в комнату. Собираюсь поменять его на девятисантиметровый, без отсека для пяти дюймовых устройств. Может получиться даже меньше чем на базе Mini ITX. Плюс у всех дома есть антресоли :-)
По производительности для фильмов:
важно на какой стороне будет происходить перекодирование. Realtek-based плееры, например, забирают файл по сети как есть и уже сами перекодируют и отдают картинку на выход. Многие телевизоры требуют DLNA сервер, который должен отдавать видео в четко определенном формате. Тут то вам мощности на стороне компа и пригодятся, чтобы на лету перекодировать видео и звук.
Я не специалист по защите от DDoS, но если есть деньги, я бы подумал об услугах специальных контор, которые могут отсекать атакующих на своих маршрутизаторах и отправлять к вам только чистый траффик, иначе вам могут просто забить каналы, и уже никакой мощный сервер на спасет, а покупать гигабитные линки это уже совсем непомерно дорого.
Но сразу скажу, лично я бы перед тем как пытаться настраивать репликацию и создавать два сервера БД, подумал бы о том, чтобы
1) оптимизировать запросы и индексы
2) переехать на дорогой хостинг с SSD (база на SSD работает намного быстрее)
3) кэшировать все по максимуму с помощью memcache
4) для отказоустойчивости использовать master-slave
Настраивать и поддерживать репликацию задача не из простых. Особенно восстанавливать все в случае падения одной из реплик. Перед тем как начать это использовать, стоит убедиться, что все другие способы решить проблему не помогают.
Я лично никогда не заплачу деньги, пока мне живой человек в трубку не скажет, что да, товар есть, да свободные курьеры завтра есть, переводите бабло, мы все организуем в лучшем виде.
А то так натыкал на сайте чего-то, перевел бабло на деревню дедушке, а магазин может закрылся уже полгода назад, а его хозяин в другой стране живет. А сайт просто забыли, так и висит. Или курьеры на неделю вперед расписаны. Или товар «обновляется на сайте в течении суток, и прямо перед вами закончился, нет деньги не вернем, выберите что-то другое». Или метеорит упал. Нет, только менеджер, только хардкор.
Прошу прощения за эмоции, но это уже правда как-то странно выглядит. Я предложил вам три решения на выбор и описал плюсы и минусы каждого, а вы вместо «спасибо» просите чего-то «более элегантного» и тыкаете меня носом в то, что я где-то раньше, до того как вы вообще описали схему БД вам неправильно говорил. Неприятно знаете ли.
> Да, согласен! Но так или иначе запросы придется все равно задавать, чтобы дополнительно вытянуть те 10 фото, те 3 опроса, те 5 видео, которые лежат в записи на стене. Вот потому я и ищу лучший путь решения…
Вы издеваетесь что ли надо мной? Да ну вас, ей богу, куда подальше. Я вам дал решение с одним запросом, вы нос воротите, я написал решение с количеством запросов по количеству типов контента — вам снова не так. Дал решение с количеством запросов по количеству записей, вы снова недовольны. Какое еще решение вы хотите? Сформулировать можете вообще?
>А Вы согласны, что Ваш ответ/комментарий habrahabr.ru/qa/37525/#comment_178863 был неполным? :)
я согласен с тем, что у вас низкий уровень компетенции по части работы с БД и вообще выражения своих мыслей. Удивительно как вы вообще умудряетесь собеседования проводить и какие-то выводы делать «по опыту».
> Наступает моммент, что при кривых запросах гуглбот создает «ддос» атаку и тогда сервер просто ложиться… и ты бросаешь все свои дела, чтобы переписать запросы и на будущее получаешь хороший урок.
ох ну блин, вообще, напугали «неопытного студента» гугл ботом. Кэширование на уровне nginx, key\value стораджа запретили чтоли? Вы решаете задачу не тем инструментом.
Если вы делаете джоины, то после первого запроса вы УЖЕ знаете, что у вас есть в какой записи. Т.е. смотрите, если у вас в записи только картинки, то вы делаете второй запрос на картинки. Имея в среднем один тип контента на запись и 10 типов контента, вы экономите в среднем 9 запросов. (если вы после первого запроса видите, что у вас нет постов блога, то их не надо запрашивать).
Если вы не делаете джоины, вы знаете только список записей на стене и должны сделать на каждую запись столько запросов, сколько у вас типов контента. Если 10 — то 10 запросов.
Вы так боитесь джоинов, просто удивительно. У вас что нагрузки планируются гигантские или вы для самообразования? Может проще пару лишних серверов в аренду взять или памяти докупить? Или ССД. Или сделайте персистент вью, с пересчетом раз в минуту. Или key-value хранилище?
Первое, что бы я сделал имея перспективы высоких нагрузок — отказался бы от MySQL хотя бы в пользу PostgreSQL. И от php за одно тоже.
Да, все так. Группировка по id и дескрипшен потому, что можно выбирать только поля, которые входят в группировку или не обрабатываются агрегатной функцией.
Объясниете, что вы понимаете под альтернативой джоинам? Вам слово не нравится? :-)
Альтернатива для INNER JOIN есть — можно перечислить таблицы в поле from и условия вынести в WHERE. Но выполняться такой запрос будет точно также как и записанный с помощью JOIN. Убедиться можете посмотрев план запроса. С LEFT JOIN такой фокус не прокатит. По крайней мере я на знаю как это сделать.
Если правильно используете ORM, то вы не должны писать запрос. В этом смысл ORM. Если вы пишите запросы для ORM, то вы либо:
-неправильно используете ORM
-используете не ORM
