ваша схема плохая :)

Misha v.3 28.05.2015 01:24 / 28.05.2015 01:26

да, она наконец внесла небольшое пояснение, что такое `номер_родительской_заявки`, но она также породила кучу вопросов, самый главный из которых -- каков смысл связи между заказами и заявками.

- `заказы`.`номер заявки` имеет тип varchar, при этом `заявки`.`номер_дочерней_заявки` имеет тип int.
- ни одно из этих полей не является PK
- но при всём этом, согласно схеме, эти таблицы связаны по данным полям (разных типов, без ключей), причём как многие ко многим. wtf? тут точно нет ошибки?

Весь замысел был в том, что можно взять, например, таблицу дочерних заявок и сделать из нее упорядоченную структуру, даже без выбора лишних данных, например:
номер_родительской_заявки
тип_дочерней_заявки
номер_дочерней_заявки

что такое тип_дочерней_заявки? :)

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

по идее хэш таблиц -- это и так многоуровневая структура со связью родитель-ребёнок по одному полю.
создать хэш таблиц руками -- дело не хитрое. создать многоуровневый хэш таблиц или хэш таблиц с вычисляемым ключём -- тоже. делается это в один проход таблицы.
зачем вы постоянно упоминаете locate -- я не знаю. его в коде быть вообще не должно в 99.9% случаях :)

P.S. приведите пример данных исходной таблицы (строк 10 данных) и многоуровневого хеша таблиц с этими-же данными, который вы хотели-бы получить.

---