Отдать клиенту, например. А уж если ему нужны детали, то он сделает запрос на их получение по id.
Отдать клиенту вы можете customer.id и это будет даже более грамотно в случае если такой записи нет. Тогда customer.id возвратит null и у клиента не будет иллюзии, что такая запись существует
1) связь может быть не по полю id, и даже не по primary key
2) тут построитель должен быть достаточно умным, чтоб не джойнить customer, а отдать ссылку на него. А если такой записи в customer нет? ну и 1 тоже справедливо
1) Речь идет именно о связи с таблицей сущностей с уникальным primaryKey, имя которого указано в foreignKey(использование иных имен кроме id мне кажется странным и непрофессиональным, но не суть)
2) Это очень простое условие, перебираются поля, если есть обращение через точку, то добавляется join. Если такой записи нет, то как сказано выше возвращается null для всех полей customer
Здесь можно было бы также сделать простейший, но вполне отвечающий психологическим особенностям человека, вывод, что производительность вырастает, когда что-то меняется.
Это почти то, но не совсем, так как в 1С это реализовано без Join, то есть если customer является id записи другой таблицы, то обращаться к customer.name можно без строчки
JOIN sales.customer customer
но в целом я бы не назвал это прям таким удобным (потому что в большинстве случаев я бы хотел видеть в объектой модели айдишки а не целые сущности)
А зачем вам id само по себе? Что вы с ним будете делать?
В любом случае тут могут быть два подхода.
1) в случае указания в запросе customer без свойств возвращать id а не целиком модель.
2) В запросе написать customer.id
За компьютерным онлайн обучением будущее. Уже давно пора стандартные лекции в школах и институтах заменить онлайн обучением, а учителей перевести в режим репетиторства и проведения семинаров, сейчас они все равно выполняют роль плохих компьютеров, загруженных устаревшей информацией.
Кроме того компьютер позволяет создать программы обучения в игровом виде. Значительно проще изучить алгебру и геометрию, играя в квест… или историю, играя в стратегию. Это все можно и должно повсеместно использовать. То, что это до сих пор не используется — просто инерция.
«Поскольку у меня скрипты на PHP все больше и больше начинают сворачиваться к одной задаче — выборке из базы данных и передаче этих данных клиентским Java-скриптам...»
Посмотрите PHP-фреймворки, из простых рекомендовал бы Yii, они придуманы именно потому, что у 90% задачи бэкенда сводятся к тому же.
PS После многих лет работы с 1С в обычных SQL-ных запросах не хватает обращения к полям связанной таблицы через точку…
То есть если у нас есть таблица sales, в котором есть поле customer, содержащие id записи таблицы customers, то для его получения можно было написать запрос вида
SELECT sales.date, sales.amount, sales.customer.name as name
FROM sales
То есть получить поле связанной таблицы без прописывания этой таблицы через JOIN в запросе. Отчасти в PHP-фреймворках это решается через модели и метод «WITH», но не так удобно. Было бы здорово увидеть реализацию подобной возможности для PHP.
Без предметного обоснования того какие недостатки 1С или конретных подсистем бюджетирования и планирования
а) Мешают ей/им быть использованными на т.н. «крупных предприятиях»
б) Не позволяют ей/им быть гибко настраиваемыми
в) Делают неконкурентноспособной производительность
Вы пишете 100% ахинею и с юридической и с точки здравого смысла. Какое дело властям страны, чем вы занимаетесь в спальне или на пляже? Как вообще они могут определить работаете вы в компьютере или в игры играете… Нелегальная работа это когда вы получаете деньги за услуги в стране пребывания, тем самым отнимая хлеб у местных. А то чем занимались ребята вообще никакого отношения к Бали не имеет. Все что получило от них Бали — это обычные туристические траты, на которые остров и живет.
«Не ожидайте, что один вариант подойдёт всем. Например, действительно ли нужен четырёхлетний опыт или достаточно двухлетнего?»
Вообще не нужно проставлять опыт как обязательное требование, потому что:
а) Вы не можете это реально проверить… Если я работал во фрилансе, как вы узнаете, что я проработал там 4 года, а не 2?
б) Это не дает никакого реального представления об уровне кандидата и может отсеять действительно способных людей с небольшим опытом. Сколько человек просиживал штаны на какой-то должности само по себе значит не очень многое, поскольку разной бывает интенсивность работы и способности разработчика.
Как верно замечено в статье тестовое задание необходимо составить таким образом, чтобы вам сразу были видны все необходимые навыки кандидата.
Когда-то я с небольшим опытом работы рассылал резюме и делал тестовые задания. Одна из компаний, в которой я был очень заинтересован, поскольку она находилась совсем рядом с домом, послала мне тестовое задание. Я его сделал, получил по почте отзыв, что сделано оно хорошо и они будут рады со мной побеседовать. Я пришел на собеседование, пообщался, через несколько дней получил отказ. На вопрос почему мне сказали, что я судя по опыту работу еще джуниор, а им нужен опытный разработчик. Тогда к чему было тестовое задание? Что им тестировалось?
По моему опыту, тестовое задание должно состоять из неявных для кандидата частей:
1) 1я часть должна включать в себя несколько небольших заданий, показывающих уровень владения человеком необходимыми технологиями
2) Пару заданий повышенной сложности на сообразительность
При этом задания первой части не должны быть определяющими, это просто индикатор того, на что успешному кандидату следует обратить внимание и подтянуть прежде чем приступить к работе. Определяющими должны быть задания второй части. Потому что если человек умеет думать, любую технологию он освоит, если не умеет — то большой практический опыт и идеальное знание технологий все равно не сделает его классным спецом и его код и решения всегда будут требовать контроля и проверки.
Пример очень удачный — практически из дзен буддизма — чтобы понять как устроен человеческий ум, породивший язык, необходимо чистое сознание. В статье же, повторюсь, попытка рассуждать о языке и порожденных им терминах и конструкций, пользуясь самим же языком и порожденными им терминами и конструкциями. Где зеркало?
Даже чтение абзацев этой статьи заставляет пожалеть о потраченном на него времени. Что уж говорить о книге. Решать на программном уровне особенности человеческого мышления, которые эти программы и создало — крайне сомнительное занятие.
Недавно устроился на свою первую работу вэб-разработчиком, ранее работал программистом в иной сфере. Никакой особой проблемы в выполнении домашних тестовых заданий не видел — это позволяло мне приобрести опыт. Иногда да, удивляло, что делая задания и не получая по ним нареканий, я не был приглашен даже на собеседование. Но еще больше удивляло, когда задание было несложное, а потом на собеседовании начинали спрашивать, сталкивался ли я в своей практике со сложными задачи и готов ли их решать? Какой смысл спрашивать это на собеседовании — дайте тест посложнее и все выяснится. И потом мне отказывают на том основании, что у меня нет опыта при удовлетворительном решении тестового задания.
Также напрягали компании, которые не давали никаких тестов на дом, а предлагали решить задачи прямо на собеседовании. Мне кажется собеседование — это место, где люди в расслабленной обстановке пытаются понять подходят ли они друг другу и когда тебе дают задачи на собеседовании, это просто может показать либо знания, которые в век интернета приобретаются за 3 минуты поиска в гугл, либо скорость реакции — например меня попросили на собеседовании написать алгоритм нахождения простых чисел — я написал, но осадочек остался, потому что когда требуется немедленное решение, ум находит первое попавшееся, а не оптимальное. Но какой смысл проверять скорость реакции, если как мне кажется, разработка должна делаться обдуманно. Поэтому как раз домашние задания, может не на 3 дня, но хотя бы на несколько часов, дают работодателю представление с каким качеством и за какой срок вы готовы разрабатывать, а разработчику уверенность, что работодатель понял, оценил и удовлетворился его уровнем. И конечно же приступая к тестовому заданию, нужно отдавать себе отчет, что работодатель вовсе не обязан вас брать.
Я поступил в итоге на работу в компанию, где было дано домашнее задание написать на php крестики нолики… Я получил от этого задания удовольствие, решение понравилось работодателю и все срослось.
function getVariantsCount(codes)
{
//Определим все последовательности цифр в коде,
//способные дать больше 2х вариантов,
//назовем их "вариативным рядом"
//вариативный ряд должен содержать в себе идущие подряд
//цифры 1 или 2 и заканчиваться ненулевой цифрой,
//которая не может составить двузначное число со следующей
var variativeRows = [];
//количество вариантов в вариативном ряде
//возрастает по числам фибоначи с увеличением размера ряда
var fibonachi = [1, 1, 2];
//колво цифр в текущем вариативном ряде
var row = 0;
var num;
//перебираем цифры кода
for(var i = 0; i < codes.length; i++){
var prevNum = num;
//если цифра 1 или 2, то увеличиваем счетчик вариативного ряда
//и переходим к следующей цифре
if((num = +codes[i]) && num < 3 && ++row) continue;
if(!num){
//если перед 0 нет 1 или 2 возвращаем нуль
//так как шифр невалиден
if(!row)return 0;
//в противном случае уменьшаем счетчик, т.к.
//цифра перед нулем может относиться только к нулю
// и не может участвовать в вариативном ряде
else row--;
} else if(num < 7 || prevNum == 1) {
row++;
}
//увеличиваем ключ с размером ряда на 1
variativeRows[row] =
isNaN(variativeRows[row]) ? 1 :
++variativeRows[row];
row = 0;
}
//увеличиваем ключ с размером последнего ряда на 1
variativeRows[row] =
isNaN(variativeRows[row]) ? 1 :
++variativeRows[row];
var variantsCount = 1;
//для каждого размера ряда определяем количество
//возможных вариаций и возводим в степень числа рядов данного размера
//полученные результаты перемножаем
for(row in variativeRows){
for(var j = fibonachi.length - 1; j < row; j++){
fibonachi[j + 1] = fibonachi[j] + fibonachi[j - 1];
}
variantsCount *= Math.pow(fibonachi[row], variativeRows[row]);
}
return variantsCount;
}
alert("вариантов: " + getVariantsCount('12612'));
function multiplyStrings(s1, s2){
var numbers = [];
var multipleLength = s1.length + s2.length;
for(var i = 0; i < multipleLength; i++) numbers[i] = 0;
//Умножаем в столбик, но не по цифре, а сразу большими разрядами,
//насколько позволяет система, в js корректно работает при следующих
//step-ах, то есть при максимальном произведении двух чисел - 15 знаков после запятой
var steps = [10, 5];
var digits = [[], []];
var stringCopies = [s1, s2];
//Заполняем массивы для умножения по заданным разрядам
for(var ind in digits){
var copy = stringCopies[ind];
var step = steps[ind];
while(copy){
if(copy.length <= step){
var part = copy;
copy = null;
} else {
var part = copy.substr(-step);
copy = copy.substr(0, copy.length - step);
}
digits[ind].push(+part);
}
}
//Умножаем в столбик
for(var i = 0; i < digits[1].length; i++){
for(var j = 0; j < digits[0].length; j++){
//Задаем сдвиг в зависимости от текущих разрядов
var shift = i * steps[1] + j * steps[0];
multipleLine = ('' + (digits[0][j] * digits[1][i])).split('').reverse();
//Произведение добавляем в массив numbers
for(var k = 0; k < multipleLine.length; k++ ){
var ind = k + shift;
numbers[ind] += +multipleLine[k];
}
}
}
//Подсчитываем каждую позицию в numbers, перенося десятки в следующий разряд
for(var i = 0; i < numbers.length - 1; i++){
var nextPos = Math.floor(numbers[i] / 10);
numbers[i] = numbers[i] % 10;
numbers[i + 1] += nextPos;
}
//Удаляем возможные лишние нули в начале
while(numbers[numbers.length - 1] === 0) numbers.pop();
return numbers.reverse().join('');
}
document.write('<br>' + multiplyStrings('654154154151454545415415454', '63516561563156316545145146514654'));
customer не NULL, а customer.id NULL — это и будет битой ссылкой
Отдать клиенту вы можете customer.id и это будет даже более грамотно в случае если такой записи нет. Тогда customer.id возвратит null и у клиента не будет иллюзии, что такая запись существует
1) Речь идет именно о связи с таблицей сущностей с уникальным primaryKey, имя которого указано в foreignKey(использование иных имен кроме id мне кажется странным и непрофессиональным, но не суть)
2) Это очень простое условие, перебираются поля, если есть обращение через точку, то добавляется join. Если такой записи нет, то как сказано выше возвращается null для всех полей customer
Это почти то, но не совсем, так как в 1С это реализовано без Join, то есть если customer является id записи другой таблицы, то обращаться к customer.name можно без строчки
А зачем вам id само по себе? Что вы с ним будете делать?
В любом случае тут могут быть два подхода.
1) в случае указания в запросе customer без свойств возвращать id а не целиком модель.
2) В запросе написать customer.id
Кроме того компьютер позволяет создать программы обучения в игровом виде. Значительно проще изучить алгебру и геометрию, играя в квест… или историю, играя в стратегию. Это все можно и должно повсеместно использовать. То, что это до сих пор не используется — просто инерция.
Посмотрите PHP-фреймворки, из простых рекомендовал бы Yii, они придуманы именно потому, что у 90% задачи бэкенда сводятся к тому же.
PS После многих лет работы с 1С в обычных SQL-ных запросах не хватает обращения к полям связанной таблицы через точку…
То есть если у нас есть таблица sales, в котором есть поле customer, содержащие id записи таблицы customers, то для его получения можно было написать запрос вида
SELECT sales.date, sales.amount, sales.customer.name as name
FROM sales
То есть получить поле связанной таблицы без прописывания этой таблицы через JOIN в запросе. Отчасти в PHP-фреймворках это решается через модели и метод «WITH», но не так удобно. Было бы здорово увидеть реализацию подобной возможности для PHP.
а) Мешают ей/им быть использованными на т.н. «крупных предприятиях»
б) Не позволяют ей/им быть гибко настраиваемыми
в) Делают неконкурентноспособной производительность
ваше утверждение останется голословным.
Вообще не нужно проставлять опыт как обязательное требование, потому что:
а) Вы не можете это реально проверить… Если я работал во фрилансе, как вы узнаете, что я проработал там 4 года, а не 2?
б) Это не дает никакого реального представления об уровне кандидата и может отсеять действительно способных людей с небольшим опытом. Сколько человек просиживал штаны на какой-то должности само по себе значит не очень многое, поскольку разной бывает интенсивность работы и способности разработчика.
Как верно замечено в статье тестовое задание необходимо составить таким образом, чтобы вам сразу были видны все необходимые навыки кандидата.
Когда-то я с небольшим опытом работы рассылал резюме и делал тестовые задания. Одна из компаний, в которой я был очень заинтересован, поскольку она находилась совсем рядом с домом, послала мне тестовое задание. Я его сделал, получил по почте отзыв, что сделано оно хорошо и они будут рады со мной побеседовать. Я пришел на собеседование, пообщался, через несколько дней получил отказ. На вопрос почему мне сказали, что я судя по опыту работу еще джуниор, а им нужен опытный разработчик. Тогда к чему было тестовое задание? Что им тестировалось?
По моему опыту, тестовое задание должно состоять из неявных для кандидата частей:
1) 1я часть должна включать в себя несколько небольших заданий, показывающих уровень владения человеком необходимыми технологиями
2) Пару заданий повышенной сложности на сообразительность
При этом задания первой части не должны быть определяющими, это просто индикатор того, на что успешному кандидату следует обратить внимание и подтянуть прежде чем приступить к работе. Определяющими должны быть задания второй части. Потому что если человек умеет думать, любую технологию он освоит, если не умеет — то большой практический опыт и идеальное знание технологий все равно не сделает его классным спецом и его код и решения всегда будут требовать контроля и проверки.
Также напрягали компании, которые не давали никаких тестов на дом, а предлагали решить задачи прямо на собеседовании. Мне кажется собеседование — это место, где люди в расслабленной обстановке пытаются понять подходят ли они друг другу и когда тебе дают задачи на собеседовании, это просто может показать либо знания, которые в век интернета приобретаются за 3 минуты поиска в гугл, либо скорость реакции — например меня попросили на собеседовании написать алгоритм нахождения простых чисел — я написал, но осадочек остался, потому что когда требуется немедленное решение, ум находит первое попавшееся, а не оптимальное. Но какой смысл проверять скорость реакции, если как мне кажется, разработка должна делаться обдуманно. Поэтому как раз домашние задания, может не на 3 дня, но хотя бы на несколько часов, дают работодателю представление с каким качеством и за какой срок вы готовы разрабатывать, а разработчику уверенность, что работодатель понял, оценил и удовлетворился его уровнем. И конечно же приступая к тестовому заданию, нужно отдавать себе отчет, что работодатель вовсе не обязан вас брать.
Я поступил в итоге на работу в компанию, где было дано домашнее задание написать на php крестики нолики… Я получил от этого задания удовольствие, решение понравилось работодателю и все срослось.