Я правильно понимаю, что вы педалируете подход, при котором на каждый чих придется вываливать из базы некоторое количество десятков мегабайт данных (нам же страшно писать хранимые процедуры, это сложна), обрабатывать их в приложении (под контролем IDE, а не схемы данных), а потом, возможно, лить обратно.
Большая гибкость, под названием "бэкэнд опять навалили хрени, которую DBA вынужден разгребать?"
Контроль за исполнением кода невозможен на стороне СУБД? Что за сказка? Вам отключили отладчик plsql за неуплату?
Ваши подходы работают до тех пор, пока структура данных может уместиться в голове у одного разработчика без влезания в документацию. Как только зависимостей и нюансов станет слишком много, придется переизобретать схему данных на стороне приложения (ура, мы напишем свой SQL, с блекждеком!).
DevMan, а я, в свою очередь, прочитал так, что классные пацаны отвинтили где-то SAS backplane, вколхозили к нему SATA-мамку и хотят воткнуть SATA-диски. То есть, из SAS тут только бекплейн. Ждем автора :)
DevMan, SATA диск в SAS воткнуть можно, этот факт легко нагугливается. Наборот - нельзя.
С экспандером | бекплейном - может повезти, может - неповезти.
tera1004, Если вы что-то там решаете, вы уже доучились курса эдак до четвертого профильной специальности, а значит, успешно сдали экзамены и зачеты по программированию - должны сами сообразить, что и как нужно добавить в программу.
Леонид, Тут сложный баланс между решением проблемы заказчика и решением хотелок заказчика. Пока что хотелки и проблема не связаны, так как не выявлено понятие "тип лица", как от этого меняется работа консультанта.
Нужно понимать, что кроме софта, потребуется еще и обучать сеть, а это может выйти дороже софта в вашем случае.
Смотря как резать... если по краям растра, то увы придется перекодировать, но как раз с обрезкой по краям кодек на видеокарте справится на отлично, если его правильно применить.
Также есть нюанс с тем, что если разрез попадет на P- или B-кадр, придется перекодировать все же кадры, попавшие в интервал между I - кадрами, другими словами, без перекодирования можно резать только по I - кадрам, что при некоторых видах монтажа может быть недопустимо.
Армянское Радио
@gbg Куратор тега Системное администрирование
ru6ak, кондиционирование, пожарку, ибп вы посчитали? Понимаете, парни, "я эту работу сделаю за три копейки, а вы все распилите", работу конечно сделают (я говорил выше, что можно обойтись одним сервером, сунув его под стул админу, можно даже взять б/у за 100к.)
но при этом, как говорил G-Man, нужно приготовиться к непредвиденным последствиям:
-если в сервере нет кассетного блока питания с раздельным подводом, не получится на горячую ни заменить БП, ни переключить сервер к другому фидеру питания
-нет промышленного резервированного кондиционера - будьте готовы к забегам по офису с охапкой вентиляторов
-нет пожарки - будьте готовы к тому, что вашу "серверную" зальют водой насквозь классные пацаны в брезентовых куртках с большими стволами
-нет внешней СХД и живой миграции - нет возможности делать ТО и ЕУ серверам без остановки сервиса.
-нет модульного ИБП - в один момент, ваш ИБП скажет вам ПИП и встанет в байпас. Заменить его без остановки сервиса вы, естественно, не сможете. А вот в модульном - легко.
Робот такого типа детально в одной голове не уместится - над ним работают коллективы из механиков, приводчиков, электроников, программистов, инженеров, математиков, специалистов по машинному обучению и нейросетям, компьютерному зрению.
Да, теоретически, такой специалист может вырасти из одной-двух базовых технических специальностей, причем вуз не важен, важна мотивация.
Большая гибкость, под названием "бэкэнд опять навалили хрени, которую DBA вынужден разгребать?"
Контроль за исполнением кода невозможен на стороне СУБД? Что за сказка? Вам отключили отладчик plsql за неуплату?
Ваши подходы работают до тех пор, пока структура данных может уместиться в голове у одного разработчика без влезания в документацию. Как только зависимостей и нюансов станет слишком много, придется переизобретать схему данных на стороне приложения (ура, мы напишем свой SQL, с блекждеком!).