Hello, I am actually scared by the fact to implement a bigger DB application on plain code level and tend rather to use a ORM.
Reason for that is that doing all DB access methods in the application language (Go or Java) tends to a codebase where you have SQL code snippets scattered over in your code. When the application now grows it will be more and more demanding to make changes. Thus, this does not scale up. Especially in the case you change to another DB system or even a newer version of your current DB bringing many disruptive changes fixing such a 100% handcrafted system is quite a big effort. ORM on the other hand enables to build a cleaner architecture but may have performance issues. These can be addressed by several means - at least in JPA - I don't know GORM: - the setup of the database schema(s) can be done manually or partly manually by pure SQL code. The ORM code then just interfaces to your database but inside the DB there may be custom solutions. The same Java code can interface to different SQL implementations thus actually the Entiy classes are only an interface. - in SQL part you can add elements which are transparent to the ORM code such as indexes or materialized views etc. JPA also have an @Index annotation that you can use but you are not forced to use it. - last not least JPA offers the opportunity to add native queries to the Java code. I don't know whether GORM has such a feature. To summarize: the basic approach would be to use ORM and detect where the performance is weak. These places are then fixed by either transparent setup in the database or by partly overwriting the ORM queries (native queries in JPA) BR, Roland -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CA%2B8p0G0PtCpkRAEt%2B_aJtqNP9RGQcBfAmzoctctuyBhchdGMTQ%40mail.gmail.com.
