Ну вот, например, пример из документации PDO (который, как я понял, вы используете для работы с БД):
$sql = 'SELECT name, color, calories FROM fruit ORDER BY name';
foreach ($conn->query($sql) as $row) {
print $row['name'] . "\t";
print $row['color'] . "\t";
print $row['calories'] . "\n";
}
Возвращает он такой же ассоциативный массив, как у вас. Неужели вся универсальность вашего подхода заключается в том, что вы запихнули инкапсулировали запрос в функцию rb() и передаете название таблицы и условие для WHERE в параметрах? Ну так это первое, что приходит в голову любому, кто начинает изучать PHP и запросы к базе данных. Поэтому действительно, ничего особенного здесь нет.
Я понял, что такое "ваш UTC". Я хотел узнать, чем ваше решение от него отличается. Начало отсчета unix time ведь находится в UTC, соответственно и сама метка тоже является временем в UTC.
Извините, я не очень понял. Как хранение времени в формате unix timestamp избавляет от отображения этого времени по-разному для разных временных зон? И чем он отличается от того, что вы называете "ваш UTC"?
Делал как-то тестовое задание, надо было реализовать параллельное вычисление числа pi методом Монте-Карло. Тоже сделал через proc_open(). Одним из условий была работоспособность на любой ОС, поэтому коммуникацию сделал через файлы. Результат можно посмотреть тут, может кому пригодится.
Хм, меня удивляет количество минусов, если честно) Аргументы какие-нибудь будут? Про синхроимпульсы с передающей станции в статье ни слова, а также я плохо представляю, как выглядит валик механического пианино, потому и спросил.
они разработали следующий алгоритм: необходимо использовать на передатчике случайный код
Какой сложный алгоритм, однако)
Смена каналов связи есть гарантия безопасной передачи информации
Угу, если противнику алгоритм смены неизвестен. Security through obscurity, тоже полезно конечно, но не гарантия.
Хотя, если честно, я из статьи не очень понял принцип алгоритма — например, в чем заключается секретность и как согласуются переходы в приемнике и передатчике. При передаче/приеме первого сигнала запускаются одинаковые валики с одинаковым расположением штырей? Если кто-то знает подробности, просветите пожалуйста.
Выскажусь с позиции новичка. Я не так давно на Хабре. Раньше мне казалось, что если я напишу хорошую статью и попаду на Хабр, то это будет означать, что я что-то стою как it-специалист, ну и просто, личное достижение. Сейчас я вижу, за какие статьи из песочницы иногда дают инвайт, и понимаю, что ничего я, в общем-то, не добился. Фиг с ним, что свою статью из песочницы я скрыл, она получилась сумбурной и непонятной. Если бы ее не пропустили, я бы постарался написать что-то еще, более нужное и интересное.
Так вот, у меня есть немного наивная мысль. Сделать специальный "внутренний круг", такой Хабр внутри Хабра. Голосовать и комментировать статьи в этом разделе могут только участники этого внутреннего круга. Попасть туда может не каждый, вернее, не все подряд. Естественно, никаких платных блогов там быть не должно, чтобы можно было быть уверенным, что там только статьи, написанные профессионалами, в которых можно найти ответ на свой вопрос или решение технической проблемы.
Это может не совсем то, что было раньше, потому что писать статьи и комментировать можно и без всякого внутреннего круга, но просто своего рода составляющая специально для гиков. Только не уверен, насколько это нужно и осуществимо.
Ну вам же не всю таблицу надо держать, а только ФИО в данном случае. Допустим, у нас миллион клиентов. Длина полного имени примерно 30-40 символов. То есть такой кеш будет занимать примерно 60-80 Мб для двухбайтовой кодировки, плюс 4 Мб на интовый ключ. После запроса делаем пост-обработку, где идем по строкам, дергаем кеш и добавляем к результату поле full_name. Никакой сложной архитектуры, один дополнительный цикл, зато минус 1 джойн из всех запросов с ФИО и связанные с ним чтения с диска и передача через сеть.
Вы, по-моему, потеряли нить разговора. Вы и автор говорите о том, что для работы с базой данных нужно обязательно знать типы джойнов и уметь реализовать их вручную, иначе разработчик это не разработчик, а оператор ЭВМ. А я говорю, что для работы с базой данных надо знать ее интерфейс, а не реализацию, и что этого достаточно во многих случаях. И что всю необходимую информацию можно узнать по ходу дела, когда это действительно понадобится. И что если человек встретился с вами на собеседовании раньше, чем со сложным запросом, для оптимизации которого надо знать типы реализации джойнов, то это не значит, что он не умеет ими пользоваться, и можно называть его оператором ЭВМ, а не разработчиком.
И да, перестаньте, пожалуйста, разговаривать с собеседником в подобном тоне. Я вас не оскорблял.
Что мне мешает запустить EXPLAIN, увидеть там nested loops, пойти в документацию и прочитать там, что это значит, какие могут быть варианты, и как на это влиять через синтаксис и настройки?
Для каждого заказа и запрашивать. Только не из базы, а из кеша в оперативной памяти. Из этого же кеша смогут запрашивать и другие списки или отчеты. Уж что-что, а ФИО клиента не меняется практически никогда.
Для этого надо знать особенности хинтов, индексов и анализатора запросов конкретной СУБД. Уметь реализовать join в программном коде для этого не нужно.
Кстати, вопрос к автору. Что именно вы ожидаете услышать в устном ответе на вопрос "как внутри работает JOIN в SQL"? Приведите конкретный пример ответа, пожалуйста. Просто чтобы знать, что ожидает услышать интервьюер.
В чем именно ложность? Вы не используете ОС или сеть?
Наука и техника развиваются много лет и многими людьми. Невозможно знать все в подробностях.
Профессионал должен знать не только свой код, но и примерное устройство соседей по стеку
Вся разница в понимании слова "примерное". Например, в моем понимании "волшебные деревья и индексы" — это и есть примерное устройство (даже с учетом того, что на собеседовании код для nested loops я бы пожалуй написал). Потому что у меня есть конкретное выражение "LEFT JOIN" в синтаксисе, и влиять на его работу я не могу. Когда я пишу запрос с джойнами, я мыслю немного другими категориями, чем вложенные циклы и выражения вида "Triple<K, V1, V2>" — например, множество, тип связи, направление (с какой стороны "1", с какой "много").
А для того, чтобы вскипятить чайник, надо в подробностях знать термодинамику. А для того, чтобы пользоваться компьютером, надо знать электротехнику и электронику. Сколько программистов может вспомнить без гугла законы Кирхгофа?
А для того, чтобы программировать, надо знать как работает защищенный режим и виртуальная память. А заодно загрузка с жесткого диска с чтением нулевого сектора и планировщик задач. А уж структуру IP-пакета точно должен знать каждый. А также уметь рассказать обо всем этом на собеседовании, и реализовать программно без IDE в Google Docs.
Возвращает он такой же ассоциативный массив, как у вас. Неужели вся универсальность вашего подхода заключается в том, что вы
запихнулиинкапсулировали запрос в функцию rb() и передаете название таблицы и условие для WHERE в параметрах? Ну так это первое, что приходит в голову любому, кто начинает изучать PHP и запросы к базе данных. Поэтому действительно, ничего особенного здесь нет.Какой сложный алгоритм, однако)
Угу, если противнику алгоритм смены неизвестен. Security through obscurity, тоже полезно конечно, но не гарантия.
Хотя, если честно, я из статьи не очень понял принцип алгоритма — например, в чем заключается секретность и как согласуются переходы в приемнике и передатчике. При передаче/приеме первого сигнала запускаются одинаковые валики с одинаковым расположением штырей? Если кто-то знает подробности, просветите пожалуйста.
А вообще интересно, спасибо.
Так вот, у меня есть немного наивная мысль. Сделать специальный "внутренний круг", такой Хабр внутри Хабра. Голосовать и комментировать статьи в этом разделе могут только участники этого внутреннего круга. Попасть туда может не каждый, вернее, не все подряд. Естественно, никаких платных блогов там быть не должно, чтобы можно было быть уверенным, что там только статьи, написанные профессионалами, в которых можно найти ответ на свой вопрос или решение технической проблемы.
Это может не совсем то, что было раньше, потому что писать статьи и комментировать можно и без всякого внутреннего круга, но просто своего рода составляющая специально для гиков. Только не уверен, насколько это нужно и осуществимо.
И да, перестаньте, пожалуйста, разговаривать с собеседником в подобном тоне. Я вас не оскорблял.
Наука и техника развиваются много лет и многими людьми. Невозможно знать все в подробностях.
Вся разница в понимании слова "примерное". Например, в моем понимании "волшебные деревья и индексы" — это и есть примерное устройство (даже с учетом того, что на собеседовании код для nested loops я бы пожалуй написал). Потому что у меня есть конкретное выражение "LEFT JOIN" в синтаксисе, и влиять на его работу я не могу. Когда я пишу запрос с джойнами, я мыслю немного другими категориями, чем вложенные циклы и выражения вида "Triple<K, V1, V2>" — например, множество, тип связи, направление (с какой стороны "1", с какой "много").
А для того, чтобы программировать, надо знать как работает защищенный режим и виртуальная память. А заодно загрузка с жесткого диска с чтением нулевого сектора и планировщик задач. А уж структуру IP-пакета точно должен знать каждый. А также уметь рассказать обо всем этом на собеседовании, и реализовать программно без IDE в Google Docs.