Обход циклов посредством жестких ссылок

[@shsmad]

Зачем понадобилось делать md5(id), если ключем в links может сразу быть id?

[@Homkas_r]

Обратил внимание на ваш комментарий, пересмотрел мой подход, и, да, очевидно что незачем было так делать, это лишняя нагрузка без смысла.

[@lair]

Многие из нас сталкивались с такой задачей: необходимо получить искомый нами объект, из массива однотипных объектов. Безусловно, эта тривиальная задача, и она легко решается при помощи обычного цикла

Задача надуманная. Покажите мне хотя бы один реальный пример, когда это действительно нужно (и при этом вы заранее знаете индексы объектов в массиве).

[@shsmad]

Массив данных берется из одной базы. Некие данные берутся из другой. К данным записей из первого массива нужно добавить некие данные из второго по некому соответствию полей и при этом сохранить порядок элементов в первом массиве.

[@lair]

Прекрасно, откуда вы возьмете массив ссылок для «массива данных из одной базы»? Посчитаете проходом по массиву? Ни что тогда мешает данные из второй базы сразу собрать в нужный хэш, а потом за один проход по массиву для каждого элемента выбрать данные из хэш-таблицы и привязать?

(но вообще сочувствую людям, у которых в платформе нет операции join)

[@shsmad]

1. Да, массив ссылок я возьму проходом по массиву
2. Помешает то, что данные из второго источника тоже массив, а значит его тоже надо пройти :) В любом случае получается пройти надо как первый массив, так и второй.
3. В данном случае речь не о платформе, в которой нет join, он то как раз есть. Речь о ситуации когда различные данные берутся из различных источников (разные типы баз, разные сервера, и т.п.)

[@lair]

Да, массив ссылок я возьму проходом по массиву

Значит, как минимум один проход по нему вам нужен все равно.

Помешает то, что данные из второго источника тоже массив

Почему это массив, а не хэш-таблица? Что мешает свернуть его в хэш-таблицу, раз уж вы не можете по каким-то причинам получить его хэш-таблицей?

В любом случае получается пройти надо как первый массив, так и второй.

Ну да, join иначе не реализуется. Вопрос в том, сколько раз вы будете проходить каждый массив. В решении с хэш-таблицами каждый массив проходится ровно один раз (т.е., не больше, чем в вашем решении), но при этом используются стандартные средства платформы.

он то [join] как раз есть. Речь о ситуации когда различные данные берутся из различных источников (разные типы баз, разные сервера, и т.п.)

Если бы у вас был join в платформе (а не на сервере БД), то вас бы не волновало, из каких источников берутся данные.

[@shsmad]

Почему это массив, а не хэш-таблица? Что мешает свернуть его в хэш-таблицу, раз уж вы не можете по каким-то причинам получить его хэш-таблицей?

Потому что это например результать fetchall() из РСУБД, а он хоть как вернет массив.

Вопрос в том, сколько раз вы будете проходить каждый массив.

Аналогично. По одному разу на массив. Для свертки в хеш-таблицу эти проходы и нужны.

Если бы у вас был join в платформе (а не на сервере БД), то вас бы не волновало, из каких источников берутся данные.

Тогда я видимо не верно понимаю, что вы понимаете под словом «платформа».

[@lair]

Потому что это например результать fetchall() из РСУБД, а он хоть как вернет массив.

Ну и сверните его в хэш-таблицу.

Для свертки в хеш-таблицу эти проходы и нужны.

Ну и что вам мешает использовать стандартные хэш-таблицы, а не hardlinks? Зачем вам лишний уровень абстракции?

Тогда я видимо не верно понимаю, что вы понимаете под словом «платформа».

В вашем случае — PHP с используемыми вами библиотеками.

[@shsmad]

Ну и что вам мешает использовать стандартные хэш-таблицы, а не hardlinks? Зачем вам лишний уровень абстракции?

Мне ничего не мешает, собственно так и делаю, хоть это и не слишком ресурсо-оптимально.

В вашем случае — PHP с используемыми вами библиотеками.

Спасибо, но я пишу на пихтоне :) Я лишь привел пример, когда может понадобиться и массив и хеш-таблица.

[@lair]

Мне ничего не мешает, собственно так и делаю, хоть это и не слишком ресурсо-оптимально.

Какой способ, по-вашему, более оптимален?

Я лишь привел пример, когда может понадобиться и массив и хеш-таблица.

Вопрос был не о том, когда может понадобиться хеш-таблица, вопрос был о том, зачем использовать «жесткие ссылки» (хотя в доках это называется просто reference).

[@shsmad]

Какой способ, по-вашему, более оптимален?

Преобразование массива в хеш-таблицу на мой взгляд гораздо более читаемый, удобный и простой в реализации вариант. Им и пользуюсь. Однако при больших объемах данных момент преобразования массива элементов в хеш-таблицу ресурсо-затратный. Впрочем, этот фактор редко когда принимается в рассчет, если это не олимпиадная задача или программирование микроконтроллеров.

Вопрос был не о том, когда может понадобиться хеш-таблица, вопрос был о том, зачем использовать «жесткие ссылки» (хотя в доках это называется просто reference).

Хм… возможно тогда между нами вышло недопонимие в чем был вопрос, ибо я понял именно как первый вариант :)

[@lair]

Однако при больших объемах данных момент преобразования массива элементов в хеш-таблицу ресурсо-затратный.

Повторяю вопрос еще раз: какой способ более оптимален?

[@Homkas_r]

В данном случае индекс — образец для лучшего понимания. Я же использую поиск по системным именам.

К примеру есть массив:

Array
(
[0] => PAGE Object
(
[Status:PAGE:private] => 1
[Id] => 1
[SystemName] => root
)

[1] => PAGE Object
(
[Status:PAGE:private] => 1
[Id] => 3
[SystemName] => root_login
)

[2] => PAGE Object
(
[Status:PAGE:private] => 1
[Id] => 4
[SystemName] => root_admin
)

…

Так как этот массив собирается используя данные из базы, в котором ID страниц увеличивается по инкрименту, то ID неизвестен, и поиск ведется по уникальному системному имени. В этом случае его будет необходимо искать перебором массива, этим метода, или альтернативным методом.

Это практический пример.

(и при этом вы заранее знаете индексы объектов в массиве).
В данном примере это не так, и тем самым задача усложняется. Этот метод решает проблему, как один из возможных быстрых вариантов решения.

[@lair]

В этом случае его будет необходимо искать перебором массива, этим метода, или альтернативным методом

Так как вы будете его искать «этим методом»? Покажите конкретный код.

[@Homkas_r]

$Key = $SystemName;
if( isset( self::$LINKS[$Key] ) == TRUE ) return self::$LINKS[$Key];

К примеру, так. Об этом и идет речь в этом посте.

[@lair]

if( isset( self::$LINKS[$Key] ) == TRUE ) return self::$LINKS[$Key];

$LINKS заполняется святым духом?

[@Xergin]

if(isset( self::$LINKS[$Key] ) == TRUE)

зачем сравнивать isset(...) с TRUE? Что за быдлокод?

[@Xergin]

Этот код у Вас для какой версии PHP?

У меня в php 5.3.15 этот код:

&$this->List[]

вызывает parse error

К тому же в php 5 $this всегда возвращает ссылку на себя.

[@sectus]

Жесткая ссылка — переменная, представляющая собой синоним другой переменной, на которую она ссылается. Чтобы создать жесткую ссылку, перед переменной необходимо написать "&".

Откуда терминология?