I've just started using Zend Framework and Doctrine as its ORM, and I have some doubts regarding the model. It's obvious that the purpose of the ORM is just to map my domain model to database model, but I'm curious how you would model various reports needed on a Web application?
From my point of view, and correct me if I'm wrong, I should avoid writing any queries in the controller (Doctrine Query Language queries, in this case). So, if I want some arbitrary report (e.g. revenue per department, split by month), should I have a special reporting "service" in the domain? This service would fetch my report from the database using ORM queries.
If you could shed some light on this topic, I'd be grateful.
For sure, sometimes DQL is insufficient. In Doctrine2 you can extend it. But Doctrine 1.x is not stupid and you can use native SQL with it: http://www.doctrine-project.org/projects/orm/1.2/docs/manual/native-sql/en
If ORM is insufficient, you can use native SQL. Reporting is the case where SQL queries become tooo complex for ANY simple QL you can image. So... I say go for native queries if you can't avoid it. But save Doctrine for everything else.
Related
I have a spring project with many Entities and a complex relationship between entities. I would like to automatically find the indexes that are missing so that I could create those indexes. Are there any tools that help in achieving this? We are using Hibernate ORM and Oracle Database.
There is a new useful feature in Hibernate: SLOW_QUERY_LOG(LOG_QUERIES_SLOWER_THAN_MS). It would help you if it really worked (HHH-13928)
There is cool (but very expensive) tool Dynatrace, which can tell you relation between a slow REST API call and particular slow SQL
And then there are Oracle's native tools like Diagnostic pack and Tunning pack. But those will not show you relation between slow SQL and piece in you code which called it.
There is common issued when there are missing indexes on FK keys. In most cases those are a must. https://www.orafaq.com/node/2935
I'm working on an IT School project, so I'm gonna explain what I'm doing. I am designing a Telemarketing Campaign Creator. The MySQL Schema and database are correctly created but I have several problems and doubts.
I'm using Zend 2 Skeleton as my start point and I'm friendly with MVC programming method, so my doubt is how to start for implementing the models from my MySQL DB for my project.
Is there a methos to generate automatically the models?
Thanks for all! =D
P.S: I'm programming under Zend Studio 10.
If you're starting from scratch with Doctrine2, I would strongly advise you to come at it the other way around: Define your entities in doctrine, and use the doctrine CLI to generate and update your MySQL schema.
Remember, with Doctrine2, your Entities (which are 'just plain php objects') are first-class citizens. Database schema is just an implementation detail.
Once you get the hang of this workflow, it's incredibly productive. When the need arises, you can pull in the doctrine migrations library, and use it to easily manage schema changes over time.
We have an app in ASP.NET MVC 3 that, due to legacy and porting reasons, is written entirely using traditional ADO.NET for the data layer.
I am now tasked with adding some reporting to this website, and the reports can result in some extremely complicated queries.
Are there any pitfalls in using the EF Power Tools to reverse-engineer a code first model and using it side-by-side with our current ADO.NET model? Doing so would allow me to use LINQ for querying the data I need, greatly speeding up the time required to write each report. I would need to shut off data context initialization, as we have our current model do that, but are there any glaring risks or problems associated with trying to do this?
If it's of any relevance (I know EF 5 has a ton of new features), we are using .NET 4 and will begin moving to .NET 4.5 as soon as it launches.
I think this is a very sensible thing to do. You could also use a database-first model, which you can refresh whenever the database changes and which does not try to initialize a database.
Since you will use the context read-only you can optimize the query process by setting the MergeOption property of ObjectQuerys to MergeOption.NoTracking. This reduces overhead because the context will not track changes of the generated objects.
A problem might be that there is more maintenance if the database changes, but I think the absence of walls of boiler-plate query code for reporting on the old data layer far outweighs that.
One day :) you may even decide to use the EF model to display data that users want to filter in the UI and use the old data layer for CUD commands. (a bit like CQRS).
Is Entity Framework 4.1 is the best solution for a web application that is using almost 400 database tables or it would best to make cutome data access layer with straight sql and sp?
The number of tables only affects EF initialization where "views" must be compiled when the context is used first time in the application - 400 is a lot and it will take a lot of time. This can be speed up by generating source code for views and adding these source codes to the project - views will not be compiled at runtime because compiled code will be part of your application but you must manually do this each time you change the model. For EFv4.1 this feature is offered in EF Power Tools CTP1. For EDMX the feature is offered in EdmGen command line tool.
Another impact on such number of tables in on development. Using 400 tables in single EDMX seems impossible so you will need multiple contexts with different sets of mapped entities. This can be complex task for application architecture because working with multiple contexts makes everything harder.
If you want to use code only mapping you must either write classes and mapping for 400 tables or you will again use EF Power Tools CTP1 which will generate them for you.
It is not impossible to use EF with 400 tables but it is complex and requires some experience.
Different people may have different views on it. Answer to your question is how you use EF whether it will be poco model or you are going to use edmx? EF performance depends on the number of records as well, so if you are using 10 tables and altogether they have 100 records then ef will perform better.
But still performance of ef on the basis of tables and records is a big question and it depends on various factors including your database designing whether it is properly normalised or not.
We do have more than 1000 tables, and we are using it (its a web app). You do not have to put everything in a single model, that would make it pretty darn hard to work on the model itself. And we are using Code Only approach, its in development yet, but everything works fine so far.
A question of ColdFusion ORM
We are using ColdFusion 9 for the past 6 months and while we've used some of the new features, ORM is something we've avoided because we usually work on the same very large website. Over the years we've used Apache OBJ but then we moved back to CF and used our own DAO objects generated from tables to handle basic CRUD. These objects are basic and need to be regenerated manually for schema changes and do not model table relationships at all. To supplement these we have a set of gateway classes for multi-table queries. While all this is very bespoke, these DAOs and gateways do, however, give us great control over the SQL we execute, for example using locking hints and optimiser hints. Our site is busy but our database is very efficient.
So much for the history lesson: the point of this is that we have a new site upcoming soon that will be written from scratch to handle financial transactions. We would normally use our aforementioned DAO objects to handle CRUD and then the usual set of gateway objects for multi-table joins but I thought we might investigate using baked-in CF ORM...
So with that in mind, I'd love to hear of the lessons, tips and tricks others might have to share in regard to using ORM on a busy financial site. For example:
What's the best way to flush your SQL ? What tips do you have for transactional ORM? How do you setup development and live sites for ORM? What about HQL? When should we just do the SQL ourselves by hand?!
Thanks in advance!
Short answer, YES! go for ORM!!!
What's the best way to flush your SQL ?
ormflush()
What tips do you have for transactional ORM?
<cftransaction> or transaction {} in CFScript works fine, and even work across DSN's, much improved in 9.0.1! watch http://tv.adobe.com/watch/max-2010-develop/coldfusion-undocumented/
How do you setup development and live sites for ORM?
same as without ORM, but you may look into this.ormSettings.dbCreate if u mean the DB creation part
What about HQL?
What about it? :) Use it when u want an array of objects, but nothing stopping you from using the good old <cfquery>
When should we just do the SQL ourselves by hand?!
When you feel like HQL doesn't do what you want.
Check out: Things to watch out for in ColdFusion 9 with CF-ORM however keep in mind that some points are no longer true for 9.0.1