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.
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.
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.
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.
We are looking for a common language for any RDBMS technology. I mean if I write a query in SQL Server that query will also have to work on any RDBMS like oracle, mysql etc.
Can anyone help get me started?
There is an ANSI standard for SQL that's (mostly) supported by most database servers. As long as you stick to that subset of the SQL language functionality offered by your database server your queries will be portable.
However, many of the more sophisticated features of your dbms won't be usable as they are not part of the ANSI standard, and thus implemented in a proprietary way by each dbms vendor - crosstabs are an example of this problem.
Two things, You could use ANSI standard but not all the RDBMS support all the ANSI standard. Also, ANSI standard are only for SQL and not fo,r say their programming language like Tsql for sql server and pl/sql for oracle etc.
2nd and most important point why would you want to use the same code in different RDBMS. Database systems are totally differnet.Some RDBMS are good in doing some things and not good in other things. Thus if you implement one code then it might not be the best optimized code for some of RDBMS's. Thus I would suggest that write the code based on the strengths and weakness of a RDBMS.If it is going to be different then so be it.
Most important thing, are you trying to do some benchmark before deciding the RDBMS. Also, what purpose it will solve to have same data and code on different RDMBS. You will be wasting lots of moeny on license. server etc as code will do the same work on all the RDBMS.
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?