Нет, потому что type-hinting для скалярных типов данных не поддерживается, поэтому придётся проверять в функции. Кроме того, если массив пуст - возврат false - неочевидное решение. Корректнее возвратить пустой массив.
if (!is_array($array)
|| empty($old_name)
|| empty($new_name)) {
return false;
}
Если устанавливать проверку, то, во-первых, нет смысла задавать пустые значения параметров по-умолчанию (функция, напротив, должна протестовать в таком случае против того, что они не переданы), а, во-вторых, проверять ключи через is_scalar - так как проверка пропустит что-нибудь наподобие объектов, что приведёт к неожиданным результатам. Кроме того, я бы вместо is_array добавил type-hinting для первого параметра.
Panoptik
Последовательность на каждом шаге - то есть, при каждом вызове функции - будет меняться (в этом суть перемешивания). Но когда скрипт будет запущен заново, код выдаст те же последовательности (формально - последовательность последовательностей будет неизменна)
armancho7777777
Кольцо полностью удовлетворяет условию задачи, поскольку происходит перемешивание в начале, и каждый элемент будет связан со случайным (если я не прав, предложите алгоритм восстановления подарившего для того, кому известно лишь то, кому дарил он сам)
А как же быть в том случае, если количество участников нечётное ?
Собственно, какая разница? Если это круговая связь, то последний замыкается на первого, таким образом, достаточно лишь обеспечить случайность выборки, что достигается через shuffle
Здесь http://forum.php.su/topic.php?fo...35&topic=794 есть такой пример. Это достаточно давние наработки из какого-то моего проекта. Там есть все вводные, однако, к примеру, нет обработки отключения клиентов (и освобождения ресурсов, соответственно) - да и уровень абстракции в лучшем случае средний. Но ясное представление о том, как с этим всем работать, тот пример должен дать.
Вертикальное шардирование может иметь смысл в ряде случаев. Например, если часты запросы, не требующие формирования полной строки данных (только малого объема имеющихся полей). Кроме того, например, MySQL хранит BLOB/TEXT поля в виде ссылок на их реальные данные на диске, так что отделение их в таблицу-партицию может оказаться полезным.
В основном, такое приносит пользу для больших таблиц, нагруженных запросами - при условии большого количества полей данных. Если приложение не будет работать под высокой нагрузкой, то это вряд ли даст ощутимый прирост производительности.