AlexLedov: как примеры:
простенький справочник, скажем так, без какой-либо бизнес-логики (только валидация) - реализовать будет легко и просто, полностью по концепции MVVM.
А вот какая-нибудь навороченная форма, которая вся состоит из взаимнозапутанных buttonclick1...buttonclick100500 - там придется по сути продраться сквозь всю логику, переосмыслить ее и сделать заново.
Своего рода "камни" полезут когда во взаимозавязаных формах или вкладках изменение выбранного значения какого-нибудь комбобокса будет требовать подгрузки/перезагрузки кучи других элементов (да еще и с сохранением selecteditem где возможно) - тут придется с религиозным рвением держаться за MVVM и не давать себе послаблений в виде "повторю-ка я цепочку, что была тут"...
Денис _______________: если не надо будет сдавать пожнадзору - то можно чуть попроще:
бочку (канистру), в донышке элетроуправляемый кран + что-нибудь термосрабатывающее
+ датчики
Денис _______________: сама жижа по ценнику вполне приемлемая, вот железяки для детекции пожара и распыления от 3М стоят конски - когда вникал в вопрос - соизмерялось с ценником на средний брендовый сервер
Евгений: имеют право любые способы, но некоторые могут оказаться "неустойчивыми".
Структура дерева с id имеет фишку, что его ветки можно легко менять передвигать, переподчинять и если в остальном живут только референсы на это дерево - то больше ничего нигде менять не придется.
если же в товаре будет жить что-то типа цепочки дерева - то эту цепочку надо будет менять при каждом изменении дерева...
Евгений: добавляем условие where c1.category=<нужная категория> or c2.parent=<нужная категория> и получаем только нужную категорию из с1 и дочерние категории
ну и join должен быть left
плюс такое прокатит для двухуровневого дерева
для дерева любой степени разлапистости - удобнее всего использовать рекурсивные cte (хз умеет ли MySQL такое), либо извращаться с временной таблицей и наполнять ее "по слоям"
The_Nex: немного далековато... (
у нас как-то с чистыми фрилансерами не срослось, поэтому поглядывали скорее на тех, кто в радиусе 100-200км от Москвы (исходя из 90% удаленки, но 10% в офисе... особенно в первое время)
Pan Propan: возможно. В последнее время я реже ими пользуюсь. Но вот относительно недавно было проблематично найти вменяемых, которые чуть-чуть хотят подумать. Как итог пришлось силами не то что не 1с-ника, а просто ученика делать модуль... который почему-то работает в разы быстрее и правильнее -)
А так бывало неоднократно что почасовики тупо делали что у них коряво заказчик попросит. Совершенно не включив голову и не остановив его, мол "так некорректно, лучше сделать вот так"...
Pan Propan: "за еду" - 100% не попадется грамотный и опытный, вероятнее попадется "проститука" - будет делать все что клиент оплачивает и ни разу его не схватит за руку в случае неправильного пути.
правда потом навечно с этим написанным будут изёживаться одинэсники-дошираковцы -)
А грамотные - будут говорить, что такой срамотой не будут пачкаться -)
p/s/ ни разу не одинэсник, но и спецов и дошираковцев повидал немало
Дима Соколов: это оказалось малоактуальным, поэтому все ядро 32-разрядное, а то что касается импорта данных из внешних access-файлов, то индивидуально у каждого клиента "настраивается" аж две строчки:
...
FROM OPENROWSET(
--'Microsoft.Jet.OLEDB.4.0', -- использовать в 32-разрядных системах
'Microsoft.ACE.OLEDB.12.0', -- использовать в 64-разрядных системах
'путь до файла .mdb'
...
Впрочем при глубоком ковырянии - данный процесс растянется надолго = без работы не остаться -)
Можно заодно замахнуться на идеологию и бизнес-логику - тогда вообще...