1. так и результат такого спроса мало предсказуем.
если не купить лотерейный билет - то есть 100% гарантия невыигрыша в лотерею.
2. деньги - не единственный ценный ресурс.
Да, время зачастую еще ценнее. Посему конечно очень логично вопрошать в интернете и жадать, ждать, ждать совершенно негарантированного в своей правильности ответа =))
Игорь: собственно РСА (autoins.ru) - это единственный первоисточник КБМ. Страховые сливают туда данные, а при оформлении страховки - добывают оттуда КБМ.
Поэтому самое логичное конечно - добывать данные у первоисточника. Совсем не исключено, что API у них во-первых засекречен, во-вторых еще и платный. Но чтобы точно это узнать - надо спросить у них.
За спрос денег не берут. www.autoins.ru/ru/about_rsa/communicate
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/ ни разу не одинэсник, но и спецов и дошираковцев повидал немало
Да, время зачастую еще ценнее. Посему конечно очень логично вопрошать в интернете и жадать, ждать, ждать совершенно негарантированного в своей правильности ответа =))