База данных большого объема обновляет с ORM
Звучит как чертовски хорошее место для использования регулярных выражений (regEx)
Вы можете написать очень чистый код проверки, например, с помощью regEx.
Я написал для вас пример здесь, но также см. Ниже: https://codesandbox.io/s/nkqx1zmp6j
импорт React из "act "; [ 115]
class Input extends React.Component {
constructor(props) {
super(props);
this.state = {
text: "",
validationError: ""
};
}
handleOnChange = event => {
this.setState({
text: event.target.value
});
};
checkPassword = event => {
event.preventDefault();
let pattern = /^(?=.*[0-9])(?=.*[!@#$%^&*])(?=.*[a-z])(?=.*[A-Z])[a-zA-Z0-9!@#$%^&*]{5,20}$/;
let password = this.state.text;
if (!pattern.test(password)) {
this.setState({
validationError:
"Your password needs a number, special character, lowercase letter, capital letter and can only be between 5 and 20 characters"
});
} else {
console.log(true);
this.setState({
validationError: ""
});
}
};
render() {
return (
{this.state.validationError}
);
}
}
export default Input;
5 ответов
Вы правы, в этом экземпляре с помощью ORM, чтобы загрузиться, измениться и затем сохранить записи не эффективно. Мой процесс проходит примерно так
1) Раннее использование реализации ORM, в моем случае NHibernate, исключительно
2) Поскольку разработка назревает, определяют проблемы производительности, которые будут включать большие обновления
3) Осуществите рефакторинг тех, которые к подходу SP или sql
4) Используйте Обновление (объектная) команда для обновления кэшируемых объектов,
Моя большая проблема сообщала другим клиентам, что обновление произошло. В большинстве экземпляров мы признали, что некоторые клиенты будут устаревшими, который имеет место со стандартным использованием ORM так или иначе, и затем начните работу, метка времени обновляют/вставляют.
ORMs являются большими для быстрой разработки, но Вы правы - они не эффективны. Они являются великими в этом, Вы не должны думать о базовых механизмах, которые преобразовывают Ваши объекты в памяти к строкам в таблицах и назад снова. Однако много раз ORM не выбирает самый эффективный процесс, чтобы сделать это. Если Вы действительно заботитесь о производительности Вашего приложения, лучше работать с DBA, чтобы помочь Вам разработать базу данных и настроить Ваши запросы соответственно. (или, по крайней мере, поймите фундаментальные понятия SQL сами),
Большинство ORMs также имеет средства для выполнения больших или "объемных" обновлений эффективно. Сессия Не сохраняющая состояние является одним таким механизмом, доступным в, в спящем режиме для Java, который, по-видимому, будет доступен в NHibernate 2.x:
http://ayende.com/Blog/archive/2007/11/13/What-is-going-on-with-NHibernate-2.0.aspx
Массовые обновления являются сомнительным дизайном. Иногда они кажутся необходимыми; во многих случаях, однако, лучшее проектирование приложений может устранить необходимость массовых обновлений.
Часто, некоторая другая часть приложения уже коснулась каждого объекта по одному; "объемное" обновление должно было быть сделано в другой части приложения.
В других случаях обновление является вводной частью к обработке в другом месте. В этом случае обновление должно быть частью дальнейшей обработки.
Моя общая стратегия проектирования должна осуществить рефакторинг приложения для устранения массовых обновлений.
ORMs просто не будет так же эффективен как изготовленный вручную SQL. Период. Точно так же, как изготовленный вручную ассемблер будет быстрее, чем C#. Зависит ли то различие в производительности вопросы от большого количества вещей. В некоторых случаях более высокий уровень абстракции, которую ORMs дают Вам, мог бы стоить больше, чем потенциально более высокая производительность в других случаях нет.
Пересечение отношений с объектным кодом может быть довольно хорошим, но поскольку Вы справедливо указываете, там потенциальные проблемы.
Однако я лично представление ORms, чтобы быть в основном ложной экономикой. Я не повторю меня здесь, но просто укажу на Использование ORM или плоскости на SQL?