Adamos

Это поговорка "В огороде бузина, а в Киеве дядька" по-айтишному.

• Microsoft SQL Server - это сервер. То есть программа, которая постоянно висит в памяти и принимает запросы от клиентов. Условно говоря - то, что и называется базой данных. Ну или точнее - СУБД, системой управления базами данных
  
• MySQL workbench и phpMyAdmin - это клиенты, то есть программы, которые могут посылать запросы на сервер. Но на Microsoft SQL Server они посылать запросы не могут, потому что работают с другим сервером - MySQL.
  
• при этом отличия между MySQL workbench и phpMyAdmin минимальные - обе являются графическими клиентами для СУБД MySQL, позволяя администрировать базу данных, редактировать таблицы в визуальном редакторе и выполнять SQL запросы. Только первое это десктопная программа, а второе - убогий веб-интерфейс, которому для работы нужен веб-сервер. И вместо которого всегда надо использовать нормальный клиент, например DataGrip, ну или хотя бы тот же Workbench.
  

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

Надо сделать несколько наблюдений: во-первых, нам без разницы, в каком порядке шары на каждом уровне - важны лишь количества там шаров всех 4 цветов. Во-вторых, если на каком-то уровне остались только белые шары - то мы этот уровень больше никогда трогать не будем. В-третьих, что бы мы не делали на одном уровне - это никак не влияет на другие уровни. Поэтому можно их все рассматривать независимо. Надо решить задачу для каждого уровня отдельно и просуммировать количество дней (и единицы, если на уровне можно что-то оставить).

Рассмотрим теперь один уровень, который описан 4 числами a,b,c,d и нам надо оставить как можно больше шаров белого цвета (их d). За один ход мы можем приравнять к 0 одно из 4 чисел и вычесть по 1 из отсавшихся ненулвевых. Ясно, что нет смысла занулять d. Т.о. за 3 хода мы можем получть 0,0,0,max(0,d-3). Но, например, если у нас было 2 2 2 3, то занулив a и b мы уменьшениями на 1 зануляем и c. Т.е. для маленьких чисел имеет смысл подумать в каком порядке их занулять. Но мне лень даже думать как именно - ведь их всего 3 числа - можно тупо перебрать все 6 перестанвок и выбрать ту, в которой за наименьшее количество ходов мы их все занулим.

1. Стоит ли делать бухгалтерии свой собственный сервер на win сервере ? (у них 3 компьютера, и стоит ли им делать AD) Три пользователя это файловая база как правило. Отдельный сервер как правило не нужен. Хотя удобнее делать те же бэкапы если базы лежат на отдельном сервере.
Сервер это функция а не характеристика. Сервер не обязан быть мощным, беспребойным, надежным, и.т.д хотя для некоторых задач это может потребоваться.
Для трех баз вполне пойдет обычная ОС с расшаренной папкой. Что -то большее - это уже надо смотреть по ситуации.
Иногда есть смысл оставить базы файловыми, но работать через сервер терминалов, иногда есть смысл перевести 1с на клиент-серверный режим работы, поставить сервер 1с и сервер баз данных. Иногда нужен или удобен веб доступ - нужен веб сервер для 1с. В общем режимов работы 1с десятки и выбирается все исходя из задач и возможностей.
В текущей ситуации я бы посоветовал оставить все как есть, только наладить бэкап. А что то менять только тогда, когда возникнет явная необходимость

2. Не могу понять как построить грамотно сеть

А что значит грамотно? Воткнули провода в коммутатор и все работает. Маршрутизатор в локальной сети не нужен. Его ставят только для соединения нескольких сетей. Например соединить две офисных сети, или соединить офисную сеть с глобальной сетью Internet.
В общем непонятно в чем у вас затруднения и проблемы.

3. Стоит ли ставить на всю организацию виндоус сервер и подключать к ним AD

Если вы четко знаете что вам не решить проблем без AD или понимаете что без него вам крайне неудобно будет работать , то конечно стоит. В остальных случаях нет, не стоит.
Мне не совсем понятно для чего там AD, но я и ситуации точно не знаю, поэтому точно сказать не могу, может и нужен.

Общий совет -
Перед тем как что-то делать, устанавиливать софт, ставить сервера, AD, и прочее нужно четко представлять для чего вы это делаете, и какие задачи это вам решит.
Ни в коем случае не стоит ничего ставить по принципу - так надо, так посоветовали, так у всех.

https://www.virustotal.com/gui/home/upload

В принципе любой. Если ближе к образцу - то он на JS. Для веб полно графических либ и движков.

Нет, на процессоре это не написано. Там написано made in China и © 2020 AMD. Это два разных предложения.

Если хотите идеал, то он должен соответствовать следующим пунктам:

1. Сериализация/десериализация - это дорогостоящее мероприятие, поэтому оно должно делаться только в двух местах: прямо на входе и прямо на выходе. Вход - это ваш контроллер, Выход - это другой сервис, куда вы передаёте данные, или база данных (тут тоже происходит сериализация, либо явно, либо в ORM). Во всех остальных слоях инфообмен должен совершаться уже при помощи объектов PHP либо нативных типов. Это экономит ресурсы. При передаче между слоями приложения объектов вместо значений либо ассоциативных массивов вы сразу будете видеть очепятки, IDE вам прекрасно поможет при помощи автодополнения, объекты могут иметь какие-то полезные методы.

2. Очень желательно в каждом из слоёв иметь собственный класс, отвечающий за данные. Например, нам в слой API приходит JSON-чик с новым пользователем.
- Сериализуем JSON в DTO UserInAPI, сразу валидируем всё то, что мы можем валидировать без слоя бизнес-логики, и либо отдаём клиенту ошибку, либо передаём сам объект UserInAPI в следующий слой: слой бизнес-логики
- В слое бизнес логики, получаем DTO UserInAPI на входе, преобразуем его в свой бизнес-объект UserInBusiness, валидируем его уже с точки зрения бизнеса, и либо возвращаем ошибку в слой API, либо совершаем над ним действия, и передаём объект класса UserInBusiness в слой работы с базой
- В слое работы с базой данных получаем на входе объект UserInBusiness, преобразуем его уже в сущность базы данных UserInDB, валидируем всё на предмет корректности данных для базы, и либо возвращаем ошибку в бизнес, либо сохраняем сущность класса UserInDB в базу.

Зачем такие сложности, вы спросите? А просто обратите внимание на то, что скорость изменения кода в разных слоях разная.
- API вообще должен меняться раз в сто лет, чтобы не злить клиентов. Поэтому DTO класс UserInAPI будет стабильным и редко будет меняться.
- Бизнес-логика меняется очень часто. У класса UserInBusiness постоянно будут добавляться поля и методы, тут жизнь будет кипеть.
- Слой базы данных будет меняться реже, чем слой бизнеса, но чаще, чем слой API, потому что нам нужны будут новые поля в базе, новые таблицы и связанные таблицы.
- И если мы один тип сущности протащим во все слои, то эта сущность обрастёт таким количеством различной хрени, что нам плохо станет, когда будем на неё смотреть. Либо она обрастёт кучей декораторов в каждом из слоёв. Поэтому лучше всё разделить.

3. Теперь внимание, казалось бы, что мы слишком сильно связываем наши слои, и нижестоящие слои знают что-то о вышестоящих, а это неправильно. Ведь мы передаём объект UserInAPI в слой бизнеса, т.е. слой бизнеса должен уметь работать с этим объектом. И так же слой базы должен уметь работать с объектом бизнеса UserInBusiness. Как же быть? А очень просто. На входе слоёв использовать интерфейсы. Т.е. в слое бизнеса мы будем принимать не сам класс UserInAPI, а объект, имплементирующий интерфейс UserIncoming, который объявим в бизнес слое, и заставим слой API сделать так, чтобы его класс UserInAPI имплементировал этот интерфейс. Таким образом слой бизнеса ничего не будет знать о слое API, а будет ждать на входе данные по контракту, описанному в интерфейсе. Бизнесу плевать на конкретную реализацию, ему нужны только методы getUsername, getEmail из интерфейса. А какой класс ему их предоставит - пофигу. Таким образом мы практически полностью разделяем слои и в два счёта сможем поменять слой API, где у нас HTTP контроллеры, на слой RabbitMQ, SOAP, Grpc и т.д.

ubuntu

https://designpatternsphp.readthedocs.io/en/latest...