разработка системы значка, где запустить бизнес-логику? В коде или хранимых процедурах? или оба? [закрытый]
Во многих местах указывается ( добавление пользовательских функций в Array.prototype ), играя с прототипом Array, может быть плохой идеей, в любом случае я сочетал лучшее из разных сообщений, я пришел с этим, используя современный Javascript:
Object.defineProperty(Array.prototype, 'immutableMove', {
enumerable: false,
value: function (old_index, new_index) {
var copy = Object.assign([], this)
if (new_index >= copy.length) {
var k = new_index - copy.length;
while ((k--) + 1) { copy.push(undefined); }
}
copy.splice(new_index, 0, copy.splice(old_index, 1)[0]);
return copy
}
});
//how to use it
myArray=[0, 1, 2, 3, 4];
myArray=myArray.immutableMove(2, 4);
console.log(myArray);
//result: 0, 1, 3, 4, 2
Надежда может быть полезна любому
4 ответа
Я рекомендовал бы поместить всю бизнес-логику в бизнес-слой. Я рекомендую это по нескольким причинам:
- Сохраняют бизнес-логику на одном языке / место
- Масштабируемость - можно разделить данные, реализовать различные механизмы кэширования, и т.д.
- , Seperation проблем - позволяют DB сделать то, что это прилагает все усилия... хранят данные, позволяют языку программирования принять решения о тех данных.
Я поместил бы его в бизнес-слой, в конце концов, это - бизнес-логика, о которой мы говорим. Хранимые процедуры могут, конечно, использоваться для задержки соответствующих данных, но я не поклонник реализации логики решения только в базе данных. Если ничто иное просто, потому что это становится более твердым и более твердым отследить то, что продолжается при пересматривании кода позже.
Я записал бы хранимую процедуру, так как вся необходимая информация находится в базе данных, таким образом, это - самое эффективное место для доступа к тем данным.
А tyical правило мог быть реализован через единственный оператор INSERT вдоль этих строк:
IF eligible for <new badge> THEN
INSERT INTO user_badges
SELECT <new_badge>
WHERE NOT EXISTS (SELECT NULL FROM user_badges
WHERE badge = <new_badge>);
END IF;
(я упрощаю несколько!)
Я знаю, что в приложении, с которым я работал, при больших объемах данных (и больших размерах таблиц), меняющихся с select * на select x, y принес нам небольшой прирост производительности. Однако я настоятельно рекомендую, как и скаффман, использовать инструмент профилирования, такой как встроенный профилировщик Oracle или внешний профилировщик, и делать большие наборы данных для нормализации шума (например, сетевой трафик, раскрутка жесткого диска, солнечные пятна и т. д.)
), которая могла бы поддерживать большую часть значков в актуальном состоянии по мере продвижения сайта.Это будет поддерживаться более тяжелой процедурой, которая могла бы пересчитывать каждый значок с нуля. Это может периодически запускаться из службы (или по крайней мере смоделированной службы ) чтобы убедиться, что ничего не было упущено, но также в ответ на изменение правил использования значков.
Я думаю, что большая часть ответа на этот вопрос будет зависеть от данных, на которых вы основываете награды за значки. Значки StackOverflow, по-видимому, основаны как на данных (ответы, вопросы, голоса и т. Д.), Так и на событиях (редактирование, изменение тегов и т. Д.). Итак - алгоритм значка, вероятно, должен запрашивать какой-то журнал аудита или журнал «действий».