Убеждение умирания твердого DBA для использования ORM для большинства CRUD по сравнению с Хранимыми процедурами, Представлением и Функциями
Печать трассировки стека в строку
import java.io.PrintWriter;
import java.io.StringWriter;
public class StackTraceUtils {
public static String stackTraceToString(StackTraceElement[] stackTrace) {
StringWriter sw = new StringWriter();
printStackTrace(stackTrace, new PrintWriter(sw));
return sw.toString();
}
public static void printStackTrace(StackTraceElement[] stackTrace, PrintWriter pw) {
for(StackTraceElement stackTraceEl : stackTrace) {
pw.println(stackTraceEl);
}
}
}
Это полезно, если вы хотите напечатать текущую трассировку стека потоков без создания экземпляра Throwable - но учтите, что создание нового Throwable и получение трассировки стека из там на самом деле быстрее и дешевле, чем звонить Thread.getStackTrace.
3 ответа
Объясните им, что создание хранимой процедуры для каждого действия, выполняемого приложением, невозможно поддерживать на нескольких уровнях.
- Если схема изменяется, это сложно отследить все хранящиеся затронутые процедуры.
- Невозможно гарантировать, что несколько хранимые процедуры не созданы для сделай то же самое, или если немного изменение существующего хранимого процедура будет серьезной разветвлений.
- Трудно убедиться, что приложение и база данных находятся в синхронизация после развертывания.
Динамический SQL имеет все эти и другие проблемы.
If you want to convince him, first you need to understand what his problem is with use of an ORM. Giving you a list of generic benefits is unlikely to help if it does not address the issues he has.
However, my first guess as to his issue would be that it prevents him from doing any optimisation because you're accessing tables directly so he has no layer of abstraction behind which to work, so if a table needs altering or (de)normalizing then he can't do it without breaking your application.
If you're wondering why a DBA would feel like this, and how to respond to it, then it's roughly the same as him coming up to you and saying he wants you to make all the private fields in your classes public, and that you can't change any of them without asking him first. Imagine what it would take for him to convince you that's a good idea, and then use the same argument on him.
Procedures used to be more efficient because of predictable caching mechanisms. However, many DBA's overkill the procedures, introducing lots of branching logic with IF commands, resulting in an scenarios where they become uncacheable.
Next, procedures are only useful if you plan to span data logic across multiple platforms; a website and separate client application, for example. If you're only making a web application, the procedures introduce an unnecessary level of abstraction and more things to juggle. Having to adjust a table, then a procedure, then a data model is a lot of work when adjusting a single model via the ORM would suffice.
Lastly, procedures couple your code to your database very tightly. If you want to migrate to a different database you have to migrate all the procedures, some of which may need to be heavily rewritten. This sort of migration is significantly easier with an ORM since you can yank out the backend and install a new one without the frontend application knowing the difference.