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...
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 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'm new with Google Web Toolkit and i have some questions about the tool.
First of all, what i have to know to correctly program for GWT? It's ok if i use the GWT Designer to make the GUI?
Second, how i persists all the data i want to store? Use JPA/Hibernate + SQL Database? Or it's better to use AppEngine?
I'm with a great doubt how i get the data from Database to populate fields and tables on client-side.
and Last, i know a bit of Swing, so, GWT is the same? (Except Client - Server concept) ?
That's my questions. Well, thanks in advance.
First of all, what i have to know to correctly program for GWT? It's ok if i use the GWT Designer to make the GUI?
Ok.
Second, how i persists all the data i want to store? Use JPA/Hibernate + SQL Database? Or it's better to use AppEngine?
It's your choice. AppEngine has it's limitations. For example, it scales but may not be the best choice for multi-player games if you need data updated very often and quickly. It really depends on your need/design.
If you do go with AppEngine, my experience with JPA was a headache. Objectify is much easier and the way I would go.
Last, i know a bit of Swing, so, GWT is the same? (Except Client - Server concept) ?
I guess they share the concept of using listeners/handlers for events. They are not the same though.
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.
I'm new in WCF. In the application there will be CRUD and also some business rules.
Please recommend what should I chose EF or LINQ to SQL?
or WCF Data Services?
To add to Pawel's points:
Use EF. Linq to Sql is mainly in maintenance mode while Entity Framework is in active development.
I recommend exploring EF Code First.
Scott Hanselman has a good intro post on EF Code First.
I'd also STRONGLY recommend Julie Lerman's EF Code First book - it'll help answer many of the questions you may have as you begin development.
Finally, be sure to keep an eye on the Data Access team's blog - EF Code First is evolving VERY quickly and lots of great features are arriving regularly (my latest favorite being migrations in 4.3) :)
HTH.
Use EF. Linq to Sql is mainly in maintenance mode while Entity Framework is in active development.
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.