SELECT * FROM `nomination` AS `nn`
LEFT JOIN `year` AS `y` ON `nn`.`id_year` = `y`.`id`
LEFT JOIN `nominees` AS `ns` ON `y`.`id_awards` = `ns`.`id_award`
WHERE `nn`.`id` = $nominationId AND `y`.`id` = $yearId AND `ns`.`id_award` = $awardId
ORDER BY `ns`.`is_win` DESC
Теоретически - да, но это будет означать, что на разных интерфейсах маршрутизатора будут находится перекрывающиеся подсети и маршрутизация работать не будет. Кроме того, в таком случае хост A будет отправлять пакет не хосту C, а самому себе, поскольку сам с собой он всяко находится в одной подсети и имеет прямой маршрут.
@merom3ro Можно и всё разбить по отдельным виртуалкам, но все сервисы под Linux обычно и так восстанавливаются на ура, достаточно сохранить конфиги из /etc, поэтому, на мой взгляд, делить Linux смысла нет, да и администрировать один сервер проще, чем три.
Windows под виртуалку придётся брать Win8 COEM DIY, Win8 VDI или WinServer OpenLicense/VolumeLicense, в противном случае лицензия не позволяет ставить его в виртуальной среде.
@artzub Отдельное поле имеет смысл при высокой нагрузке, когда запросов на чтение счётчика очень много, а на добавление/удаление статей мало. В этом случае поле изменяется по триггеру и выполняет роль кэша.
@13KOLDUN Если допускается простой в течение суток и/или потеря данных 1С за сутки, то система и файлы 1С на SSD, файлы видеорегистратора на отдельный винт, файлопомойка на отдельный винт, ежесуточный бэкап данных 1С на другой комп или на Dropbox, на одном из компов подготовить место для развёртывания резервной копии базы. Если требования по надёжности более жёсткие, то смотреть в сторону аппаратного raid и пары быстрых SAS-винтов для системы и 1С.
@iproger Как ни странно, но у меня первая ссылка по этой строке из гугла ведёт не на то, что такое BNF, а на часть RFC 2616, описывающий HTTP/1.1. Так что гуглить можно, когда представляешь себе что надо искать и можешь описать проблему в подходящих формальных терминах. Чем большее представление имеешь о различных областях знаний тем легче искать, а со врменем и искать не приходится.
И ещё, разница в цене появилась где-то с полгода назад. Мелкомягкие объясняли, что многие пользователи работают с рабочего компа, домашнего компа, да ещё и с планшета. Поэтому-де лицензия на пользователя должна быть дороже.
Да, но берётся по тому, чего меньше. Поскольку при лицензировании на девайс нет разницы, сколько человек за ним по очереди работают, а при лицензировании на юзера неважно со скольких устройств он подключается к терминалу.
@Kerman C SATA ситуация редкая, у меня на пяти серверах с Raid-1 и Raid-10 на материнке за три года было два таких случая. Ещё был случай перехода в degraded при неожиданном отключении питания.
Стоит 8.2 в терминалке (2x Xeon X5550) на 100 юзеров. Клиент 1С в пике отъедает до 10 % от одного ядра, криво написанная обработка может съесть всю оперативку.
MS SQL и сервер приложений 1С вынесены на отдельную машину (i7-3770), редко когда загрузка ядер выходит за 20 %, а средняя загрузка проца в рабоче время около 8 %.
WinRmtDsktpSrvcsCAL 2012 RUS OLP NL DvcCAL - 3291 р.
WinRmtDsktpSrvcsCAL 2012 RUS OLP NL UsrCAL - 3781 р.
WinSvrCAL 2012 RUS OLP NL DevCAL - 950 р.
WinSvrCAL 2012 RUS OLP NL UsrCAL - 1091 р.
Так что и лицензии разные, и цена у них разная. usr/dev CAL в последний раз видел на 2003 сервере.И, кстати, в вашем примере 50 юзеров и 40 девайсов надо брать
WinSvrStd 2012R2 RUS OLP NL 2Proc - 1 шт.
WinRmtDsktpSrvcsCAL 2012 RUS OLP NL DvcCAL - 40 шт.
WinSvrCAL 2012 RUS OLP NL DevCAL - 40 шт.
Согласен, это гораздо эффективнее полного перебора. Но попробуйте посчитать не просто разбиение массива чисел на группы, а полное количество вариантов выражений, которые можно составить используя n цифр.
@13KOLDUN На Raid-2 и выше для записи сектора на один из винтов необходимо сначала считать соответствующие сектора с остальных винтов (кроме контрольной суммы), пересчитать контрольную сумму, а потом уже записать нужный сектор и новую контрольную сумму. При этом в Raid-3 все контрольные суммы пишутся на один винт, из-за чего нагрузка на запись у него заметно выше, чем у остальных винтов в рейде. Чтобы этого избежать используют Raid-5, у которого контрольные суммы распределены по всем винтам. Для сочетания скорости и надёжности используют Raid-1 или Raid-10 (1+0), в этом случае сектор записывается сразу на два винта, а считывание идёт поочерёдно с каждого из винтов (для Raid-10 возможно одновременное позиционирование на разные сектора четырёх винчестеров). Но платить за это приходится половиной объёма винтов.
Думаю, что после первого запроса и в том и в том случае информация пойдёт из кэша. Для экстраполяции на одиночные запросы надо делать перебор по 1000 разных каталогов и соответственно по 1000 разных id в базе.
