As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In the seemingly eternal struggle between ORM and SQL-programming, there comes a question:
Why not use both? Using ORM for most of the programming, and program my own SQL-queries for the more complex JOIN-queries and other complex queries the chosen ORM cannot do. Are there any good reasons not to?
Most ORM solutions support native SQL - e.g. Hibernate.
The reason NOT to combine the two is one of consistency - if you have to understand two ways of retrieving data from the database and converting them to objects in your application, you have twice as much to remember, twice as many opportunities for bugs, and twice as much testing to do (for the "connect to database and retrieve data" code).
What happens in practice is that developers who are not comfortable with ORM will tend to use native SQL, and developers who like the ORM tool will do nearly everything using the ORM layer - this will make your codebase hard to maintain and extend.
If you're going to do this, I'd at least enforce the "do SQL through the ORM tool, not directly through JDBC (or whatever)" rule - that gives you at least some consistency, and you can re-use a lot of the object mapping functionality.
Ideally, though, pick a solution and stick with it - hedging your bets is rarely free.
Most of the cases ORM generated SQL are non-optimized.
It is suggested where performance matters that, Use ORM for binding only and use user-defined SQL for all the queries.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
How deep knowledge of T-SQL do I need to have in order to fully grasp all concepts of EF (Entity Framework)?
To be more precise, currently my knowledge of SQL is not small. I know all the basics very well as well as some intermediate concepts like stored procedures, UDF, trigers etc.
But do I need to know things such as XQuery and XPath, SQL CLR Programming or Catalog Views and Dynamic Management Views to fully understand EF or this is not needed as EF has it's own way of achieving the same thing?
I hope you don't find this question stupid as it will save me some time due to my novice knowledge of EF.
I have to add that I am not a database administrator nor will I be (at least for now) but a .NET developer learning EF.
Basically, you have to know less with EF than without it. It shields you partially from the underlying database technology. You kind of have to accept trade-offs the less you know (worse performance or inelegant design). But you don't need any of the things you quoted:
But do I need to know things such as XQuery and XPath, SQL CLR
Programming or Catalog Views and Dynamic Management Views to fully
understand EF or this is not needed as EF has it's own way of
achieving the same thing?
Because mostly, they are not supported by EF anyway...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am planning to use IndexedDB to support offline database but having trouble in performing queries and understanding the underlying mechanics of it. Is there a indexeddb wrapper that can enable me to query against indexeddb using SQL queries? Thanks!
Check out my wrapper library https://bitbucket.org/ytkyaw/ydn-db It will support limited SQL like appengine GQL.
IndexedDB API do not have relational concept nor SQL processor, but relationship is basically relating two object stores by a pair of respective fields. Handling relationship directly is often more efficient than declarative SQL in javascript usage. With declarative SQL language, you tell everything about what you want and wait for the result. OK for backend, not ideal for frontend.
With IndexedDB you don't wait, just open stream of records (cursor) and decide what to do next in each iteration. It is more flexible and much faster. Check out ydn.db.ICursor for these concept.
Currently, the library is very active stage and not ready thought.
As far as I know, there isn't. But I have a wrapper that is using a LINQ interface to query on the indexeddb: linq2indexeddb.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In a class on dbms we are taught to "make the solution in relational algebra" before converting to SQL. It really has become second nature and it's almost difficult to directly write SQL. Is this bad or good? I'm told it leads to better queries which is good but I can see a person getting fired quick if every time their asked to find something in a database they start writing math on a piece of paper.
You can see someone getting fired for working out a solution to a problem before rushing into it?
It's always, always good to work out whatever you need to before coming up with a solution. Over time, as your skill progresses, you'll find you don't need to prep as much.
It is a good thing.
Too many programmers come to SQL without thinking relationally and end up using cursors and looping mechanism that are not suitable to SQL as relational databases are optimized for relational algebra.
Well, the point with relational algebra is that it's universal. It's not specific to one DBMS. So more people can understand it.
It might be more a theoretical stuff that you will see only at school and not really in practice but it's not a bad practice. It can help you before you start writing your query and consequently save time
I would be surprised if your boss fire you because you didn't do your relational algebra before your query or vice versa.
Also, some people use it to optimize their queries
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In this day and age, with a new NoSQL databases popping up every weekend..
Are there any good and up-to-date resources on how to pick a database(s) that will suit your web application needs?
If you're interested in trade-offs and feature comparisons Wikipedia tends to be updated more than others.
Relational Database Comparison: http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
NoSQL Feature Comparison: http://en.wikipedia.org/wiki/Comparison_of_structured_storage_software
If you want a more direct answer you can always post the requirements you have and you'll get a lot of helpful answers. It's a pretty broad subject and, other than feature comparison matrices like the ones above, you'll mainly get subjective answers unless you have an objective question (ie specific requirements).
Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j comparison
NoRAM DB => “If It Does Not Fit in RAM, I Will Quietly Die For You”
Although I would also advise considering a SQL data back end ( e.g. PostgreSQL, Drizzle ) with a cache layer, e.g. Redis on top of it. Unless you have an actual reason to use NoSQL. The reason can by the way be NoSQL is cool and I'd like to learn it, but if that is all, usually it may hurt at the end.
Does the problem have to do with money transactions? Are you going to have a distributed system?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why do some frameworks (like CakePHP, Kohana, Zend, Django, less - Rails) create some kind of SQL abstractions instead of a raw SQL database access? E.g. why do we need to make some perversions instead of a usual queries?
UPD: are there any SQL-injection reasons of this purpose?
Basically a good abstraction layer makes it easier for the developer to use a database, and not care what what and which kind of database he is connecting to, thus speeding up the development process.
Check out http://en.wikipedia.org/wiki/Database_abstraction_layer, the most common pros and cons are listed here.
Thats called abstraction. Usually its done to be db specific indipendent.
Sql will be built based on the db type of the connection..
There are two main reasons.
Database Indepence
The code can be applied to different databases. MySQL, MS SQL-SERVER, ORACLE. And with a little wrangling to other DBs using OBDC like MSAccess, or CSV files.
Separation of Database Code with Business Logic
Most frameworks follow this model: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
It's primarily an attempt to reduce what's known as the impedance mismatch between the relational storage of the database and the domain model within your application. Without the ORM you often find yourself writing "left hand right hand" code modelobject.property = reader["field] where you're mapping values from the storage format you've received from the database into your model.
In summary, hopefully the ORM allows you to concentrate on solving the business problems without having to worry about all of the plumbing. We're not there yet but we're getting close.