Евгений: имеют право любые способы, но некоторые могут оказаться "неустойчивыми".
Структура дерева с 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'
...
Дима Соколов: Вообще у меня, точнее у клиентов вполне успешно работает подобная конструкция.
Условно говоря две версии - для 32 и 64 разрядов, которые отличаются только этими строками.
То есть на 32-разрядных системах - используется подключение Jet, а на 64-разрядных - ACE.
Танцы с установкой 32-разрядных версий на 64-разрядки при наличии установленного офиса - ну их нафиг.
Fortop: главное, чтобы действительно третье звено было действительно не пятым колесом... А то сейчас своего рода "трехзвенка" в виде "нифига не понимаю в sql, поэтому втащу все себе в пхп и там циклами разрулю, а потом солью клиенту полсотни жабаскриптов" - достаточно распространенная штука... Которая в итоге требует широчайшего канала между sql-сервером и web-сервером, широкого канала до клиента (ибо страничка раздута на десяток мегабайт) и компьютера помощнее (ибо свистелки-перделки требуют вычислений на клиенте как хороший рендерер) (
