Comments 20
Зачем понадобилось делать md5(id), если ключем в links может сразу быть id?
Многие из нас сталкивались с такой задачей: необходимо получить искомый нами объект, из массива однотипных объектов. Безусловно, эта тривиальная задача, и она легко решается при помощи обычного цикла
Задача надуманная. Покажите мне хотя бы один реальный пример, когда это действительно нужно (и при этом вы заранее знаете индексы объектов в массиве).
Массив данных берется из одной базы. Некие данные берутся из другой. К данным записей из первого массива нужно добавить некие данные из второго по некому соответствию полей и при этом сохранить порядок элементов в первом массиве.
Прекрасно, откуда вы возьмете массив ссылок для «массива данных из одной базы»? Посчитаете проходом по массиву? Ни что тогда мешает данные из второй базы сразу собрать в нужный хэш, а потом за один проход по массиву для каждого элемента выбрать данные из хэш-таблицы и привязать?
(но вообще сочувствую людям, у которых в платформе нет операции join)
(но вообще сочувствую людям, у которых в платформе нет операции join)
1. Да, массив ссылок я возьму проходом по массиву
2. Помешает то, что данные из второго источника тоже массив, а значит его тоже надо пройти :) В любом случае получается пройти надо как первый массив, так и второй.
3. В данном случае речь не о платформе, в которой нет join, он то как раз есть. Речь о ситуации когда различные данные берутся из различных источников (разные типы баз, разные сервера, и т.п.)
2. Помешает то, что данные из второго источника тоже массив, а значит его тоже надо пройти :) В любом случае получается пройти надо как первый массив, так и второй.
3. В данном случае речь не о платформе, в которой нет join, он то как раз есть. Речь о ситуации когда различные данные берутся из различных источников (разные типы баз, разные сервера, и т.п.)
Да, массив ссылок я возьму проходом по массиву
Значит, как минимум один проход по нему вам нужен все равно.
Помешает то, что данные из второго источника тоже массив
Почему это массив, а не хэш-таблица? Что мешает свернуть его в хэш-таблицу, раз уж вы не можете по каким-то причинам получить его хэш-таблицей?
В любом случае получается пройти надо как первый массив, так и второй.
Ну да, join иначе не реализуется. Вопрос в том, сколько раз вы будете проходить каждый массив. В решении с хэш-таблицами каждый массив проходится ровно один раз (т.е., не больше, чем в вашем решении), но при этом используются стандартные средства платформы.
он то [join] как раз есть. Речь о ситуации когда различные данные берутся из различных источников (разные типы баз, разные сервера, и т.п.)
Если бы у вас был join в платформе (а не на сервере БД), то вас бы не волновало, из каких источников берутся данные.
Почему это массив, а не хэш-таблица? Что мешает свернуть его в хэш-таблицу, раз уж вы не можете по каким-то причинам получить его хэш-таблицей?
Потому что это например результать fetchall() из РСУБД, а он хоть как вернет массив.
Вопрос в том, сколько раз вы будете проходить каждый массив.
Аналогично. По одному разу на массив. Для свертки в хеш-таблицу эти проходы и нужны.
Если бы у вас был join в платформе (а не на сервере БД), то вас бы не волновало, из каких источников берутся данные.
Тогда я видимо не верно понимаю, что вы понимаете под словом «платформа».
Потому что это например результать fetchall() из РСУБД, а он хоть как вернет массив.
Ну и сверните его в хэш-таблицу.
Для свертки в хеш-таблицу эти проходы и нужны.
Ну и что вам мешает использовать стандартные хэш-таблицы, а не hardlinks? Зачем вам лишний уровень абстракции?
Тогда я видимо не верно понимаю, что вы понимаете под словом «платформа».
В вашем случае — PHP с используемыми вами библиотеками.
Ну и что вам мешает использовать стандартные хэш-таблицы, а не hardlinks? Зачем вам лишний уровень абстракции?
Мне ничего не мешает, собственно так и делаю, хоть это и не слишком ресурсо-оптимально.
В вашем случае — PHP с используемыми вами библиотеками.
Спасибо, но я пишу на пихтоне :) Я лишь привел пример, когда может понадобиться и массив и хеш-таблица.
Мне ничего не мешает, собственно так и делаю, хоть это и не слишком ресурсо-оптимально.
Какой способ, по-вашему, более оптимален?
Я лишь привел пример, когда может понадобиться и массив и хеш-таблица.
Вопрос был не о том, когда может понадобиться хеш-таблица, вопрос был о том, зачем использовать «жесткие ссылки» (хотя в доках это называется просто reference).
Какой способ, по-вашему, более оптимален?
Преобразование массива в хеш-таблицу на мой взгляд гораздо более читаемый, удобный и простой в реализации вариант. Им и пользуюсь. Однако при больших объемах данных момент преобразования массива элементов в хеш-таблицу ресурсо-затратный. Впрочем, этот фактор редко когда принимается в рассчет, если это не олимпиадная задача или программирование микроконтроллеров.
Вопрос был не о том, когда может понадобиться хеш-таблица, вопрос был о том, зачем использовать «жесткие ссылки» (хотя в доках это называется просто reference).
Хм… возможно тогда между нами вышло недопонимие в чем был вопрос, ибо я понял именно как первый вариант :)
В данном случае индекс — образец для лучшего понимания. Я же использую поиск по системным именам.
К примеру есть массив:
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 неизвестен, и поиск ведется по уникальному системному имени. В этом случае его будет необходимо искать перебором массива, этим метода, или альтернативным методом.
Это практический пример.
(и при этом вы заранее знаете индексы объектов в массиве).
В данном примере это не так, и тем самым задача усложняется. Этот метод решает проблему, как один из возможных быстрых вариантов решения.
К примеру есть массив:
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 неизвестен, и поиск ведется по уникальному системному имени. В этом случае его будет необходимо искать перебором массива, этим метода, или альтернативным методом.
Это практический пример.
(и при этом вы заранее знаете индексы объектов в массиве).
В данном примере это не так, и тем самым задача усложняется. Этот метод решает проблему, как один из возможных быстрых вариантов решения.
$Key = $SystemName;
if( isset( self::$LINKS[$Key] ) == TRUE ) return self::$LINKS[$Key];
К примеру, так. Об этом и идет речь в этом посте.
if( isset( self::$LINKS[$Key] ) == TRUE ) return self::$LINKS[$Key];
К примеру, так. Об этом и идет речь в этом посте.
Этот код у Вас для какой версии PHP?
У меня в php 5.3.15 этот код:
вызывает parse error
К тому же в php 5 $this всегда возвращает ссылку на себя.
У меня в php 5.3.15 этот код:
&$this->List[]
вызывает parse error
К тому же в php 5 $this всегда возвращает ссылку на себя.
Жесткая ссылка — переменная, представляющая собой синоним другой переменной, на которую она ссылается. Чтобы создать жесткую ссылку, перед переменной необходимо написать "&".
Откуда терминология?
Sign up to leave a comment.
Обход циклов посредством жестких ссылок