I have a question about Orm or RAW sql
Can you tell me which one I should choose if I want to create a large-scale project? And why?
ORM and Raw SQL both have their own pros and cons.
Deciding which to use would depend on your app requirements.
When using Prisma, you could use its capabilities but also have an option to resort to Raw Queries if needed by using queryRaw or executeRaw methods.
Prisma is a new kind of ORM that fundamentally differs from traditional ORMs and doesn't suffer from many of the problems commonly associated with these.
In Prisma, you define your models in the declarative Prisma schema which serves as the single source of truth for your database schema and the models in your programming language which could be a huge benefit!
Here are the cases in which prisma would be a good fit: Comparison
Related
I'm currently trying to figure out how powerful ORMs are. I've written pretty simple web applications where you just needed simple CRUD queries and was super happy with the ORM I was using. But for complex analytical queries I didn't even attempt to use the ORM. It might very well be that in the specific cases it was just my limited knowledge. But on a more general note, are there any statements about any ORM that they can / cannot represent any possible SQL query? How powerful are ORMs?
(I'm most familiar with SQLAlchemy of Python)
Please note:
Yes, many ORMs support sending raw SQL. I don't consider that part of the ORM, though. My question is specifically about the ORM part only.
It's subtle. The point of an ORM is to map object to relational constructs. The ORMs I've used (mostly based on the ActiveRecord pattern) do a really good job of mapping basic SQL constructs into the object-oriented development language, and allowing you to reason at the level of an object instance in your app, rather than rows, columns and joins. As you note, this really accelerates CRUD development tasks.
In theory, I think it is possible to represent every SQL Query to an ORM construct (assuming the ORM supports all the SQL constructs in the underlying database engine).
But you probably don't want to. If your application manages orders, having CRUD functionality from the ORM is really useful. But to write the report showing order values by sales person by month in a tabular layout would involve lots of ORM complexity, but could be represented in a fairly simple SQL Query. While the ORM may support every language construct from the underlying database engine, it probably doesn't make any promises about performance.
I am really confused because I have heard a lot about ORM, I guess the best practise is to used ORM to not write SQL queries.
I tried Django ORM, Laravel ORM, Hibernate and they take much longer time to return the data.
For example: I code a script to insert a dataset using native queries and Django ORM, Django takes 4 minutes and my script take 1 minutes, more or less.
I think the response time is the more important thing when you code an api.
So, is not a better option to use the query builder?
ORM is basically a way to introduce concepts of domain and type safety into work with databases. When you can have classes and properties with types, it's more easier to write logically structured and type safe code, also reuse existing functionality. Following these benefits, the main advantage of ORM is safety and clearness.
Also, ORM could be a way to introduce an abstraction layer, allowing semi-painless migration from one database to another as details of interaction are hidden inside ORM engine.
For small projects without many developers working on or for application with short lifetime, it's obviously not a necessity, and introduction of an ORM can be considered as a disadvantage.
Addressing your example with slow insertion of data and accusation of ORM, it can be said that probably you aren't using ORM correctly or you are using it not in the most optimized for the task way. For example, your script can use no transactions at all or probably use less restrictive isolation level whereas ORM can target safety over speed, creating a transaction on each insert or utilizing more restrictive isolation level.
Please mention the difference between (big) ORM and micro ORM. What are the advantages of micro ORM over big ORM. For eg. the difference between entity framework ORM and dapper micro ORM.
They are simply different tools. The key goal of micro-ORMs is to remove a lot of layers that an awful lot of data access code doesn't need - basically providing a minimal API surface and trying to balance that by offering the performance benefits that can come from simplicity. For example, things that you would expect to find in an ORM but might not be available in a micro-ORM include (depending on the specific tool being used, and the additional extension libraries being brought on):
lazy loading of child members (perhaps via polymorphic runtime type generation, perhaps via code-gen)
identity tracking
change tracking
a rich complex mapping system that supports arbitrary data models on multiple backend databases
complex query generation from complex LINQ expression trees or some other DSL
a unit-of-work API - essentially a SubmitChanges() method that figures out and applies a batch of related changes
Note that they aren't mutually exclusive: you can use both approaches in the same code-base, depending on what you need in different places.
I like to use a GUI application to design databases using ERD. Currently I am using the EER Diagram of the free MySQLWorkbench.
Once I like the way the ERD looks, I Forward Engineer the ERD in MySQLWorkbench to create the actual database. Then I introspect the MySQL database with django-admin.py inspectdb to Reverse Engineer into an output of a Python snippet code for Django's models.py.
But then I have to take the inspectdb output and manually edit it to my liking. One particular part I really don't like to do is manually eliminating each join table from a many-to-many relationship.
Is there a good (and preferably free) GUI ERD design program out there specifically designed for Django?
If you wish to design your models at the database level, in the way that you're describing, you are going to need to do exactly that: design your SQL and then convert that into Django models.
This is not the normal way of designing a Django application: typically you would design the models as you wanted them to be, and only put a lot of effort into schema design if you need to resolve some performance problems. Django models aren't really meant to be an abstraction of a relational database: they're meant to be an abstraction of your application's persisted objects, which happens to be implemented on top of a relational database.
There is nothing wrong with wanting/needing to do an explicit schema design, but it makes you a bit of an outlier (most web devlelopers don't), hence the difficulty you're having finding tools suited to your needs.
The closest thing is the graph_models command which is part of Django command extensions. This lets you visualize your models (you still write them in python code, but the visual representation will help you iterate faster).
It is not usual to design a database layout for django apps as such, and doing so is likely to lead to a sub-optimal design.
Instead, just design your model classes, taking account of how you will query them, and the way that ForeignKey (and the other relations types) work. If you don't do this, you are likely to find that your app suffers from conceptual mismatch.
I am a little bit confused about Dataset compared to ORM (NHibernate or Spring.Net). From my understanding the ORM sits between the application layer and the database layer. It will generate the SQL commands for the application layer. Is this the same as what Dataset does? What is the difference between the Dataset and ORM? What are the advantages and disadvantages for these two methods? Hope the experts in here can explain something.
Thanks,
Fakhrul
There is a BIG difference between them, first of all about the programming model they represent:
The Dataset is based on a Table Model
An ORM (without specify a particular product of framework) is based and tends to a Domain Model.
There is another kind of tool which could be used in data scenario, this kind of tool is a Data Mapper (eg. iBatis.NET)
As others answers before me, I think it's important to view what Microsoft says about Dataset and better what Wikipedia says about ORM, but I think (this was for me at beginning) it's more to understand the difference between them in terms of model. Understanding that will not only clarify the choises behind but better, will do too easy to approach and understand a tool itself.
As little explanation it's possible to say:
Table Model
is a model which tends to represent tabular data in a memory structure as close as possible (and even as needed). So it's easy to find implementations which implements concepts as Table, Columns, Relations in fact the model is concetrate on the table structure, so object orientation is based on that not on data itself. This model could has its own advantages, but in some case could be heavy to manage and difficult to apply concepts on contained data. As previous answers says, implementations like Dataset, let, or better, force you to prepare (even if with a tool) needed SQL instructions to perform actions over the data.
ORM
is a model which (as mendelt says before me..) where Objects are mapped directly to database objects, principally Tables and Views (even if it's possible to map even functions and procedures too). This is done in 2 ways generally, with a mapping file which describes the mapping, or with (in case of .NET or Java) code Attributes. This model is based on Objects which represents the data, so object orientation could be done on them as in normal programs, it's clear with more attention and caution in certain cases, but generally, when you are confident with ORM it could be a really powerfull tool! Even ORM could be heavy to manage if it's not managed and designed well, or better understood weel, so it's important to understand techniques, but I can say with my experience that ORM is a really powerfull tool. In ORM, the tool principally it's responsible to generate the SQL instructions needed as operations are done in code, and in more cases ORMs has a middle language (like HQL) to perform operations on Objects.
MAPPER
A mapper is a tool which doesn't makes things like an ORM, but, maps hand written SQL instructions to an Object Model. Thi kind of tool could be a better solution when it's needed to write by hand SQL instructions but It's wanted to designe an application Object model to represent data.
In this "model" objects are mapped to instruction and described in a mapping file (generally an Xml file as iBatis.Net or iBATIS (java) does). A mapper let you define granular rules in SQL instructions. In this scenario could be easy to find some ORM concepts as for example session management.
ORM and Mappers let to apply some very interesting Design Patterns, which could be not so easy to apply in the same way to a Table Model and in this case to a Dataset.
First of all excuse me for this long answer and about my poor english, but for me, an answer like this makes me in past to understand well the difference between this models and then between implementations.
the Dataset class is definitly not an ORM; an ORM maps relational data with an object oriented representation.
It can be regarded as some kind of 'unit of work' though, since it keeps track of the rows that have to be deleted/updated/inserted.
ADO.NET DataSet =
http://msdn.microsoft.com/en-us/library/zb0sdh0b(VS.80).aspx
ORM =
http://en.wikipedia.org/wiki/Object-relational_mapping
(Example Developer Express
XPO,DataObjects.NET)
ORM is based on mapping between objects and tables. Not the case for this dataset. Dataset is itself in a way directly to the table. ORM is based on a minimum of SQL script. But enough to use the dataset you write SQL clause. Dataset in this case is not an ORM.
Look at dataset and ORM.
No, Datasets are not ORM's. They may look like orms because datasets map tables to objects just like ORM's the main difference lies in what objects they map to.
Datasets have their own table and row object types that closely resemble the structure of the database. You're rebuilding part of the database's relational model in objects. Restricting these objects into something resembling a relational database gets around some of the problems inherent in mapping a database to an object model.
An ORM maps the tables and rows from the database into your own object model. The structure of your object model can be optimized for your application instead of resembling a relational database. The ORM takes care of the difficulties in transforming a relational model into an object model.
DataSet is a DTO, a data transfer object. DataSet itself can't do anything. You can use a DataAdapter (of the provider used) to produce sql or call predefined queries, though it still isn't doing anything.