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
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 have experience over Relational DB's but very little over NoSQL data stores and for these two I need a well defined reason to say that one needs to move to NoSQL.
Since I cannot replicate a situation where I can push a DB to its limits and make it lose performance, let alone scaling it. Therefore wondered about to see what others had to say. May be I have been treading the wrong path path, but I have read people saying why we should move to NoSQL or how or even at what sort of different scenarios eventually leads to NoSQL. Article after article explains what Big Data is and how it is managed in the NoSQL domain and how useful it is with it architecture of being scalable, robust, ACID, BASE, Data modelling from Sql to NoSQL, etc features.
But none would provide some solid numbers. E.g. A web service that had a DB of X-TB's and eventually the queries (read/write/etc) took T-seconds or so to complete so we moved on to NoSQL to get back the performance. My concern is at what point it really did a team shift to NoSQL when they said, OK we're done with scaling and everything, lets move on to NoSQL!
So I have had to ask SO users. Maybe someone can share some valuable information. This seems to be an open issue for me as I have been trying to get hold of even just one document that explains a real case scenario where the SQL DB eventually had to be replaced with a NoSQL DB/DS/storage.
Any guidance is much appreciated.
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 a java developer, currently starting developing a hospital management system that will server patients, doctors, accountant, .... etc the system is really huge that may have 900,000 records/day, data is really growing so fast, for that i'm confusing in which database to use since i have the following options: (Percona Server(Mysql), Oracle, SQLServer), since the application will run on network with average of 45 online users.
I hope to find a good answers here.
Thanks in advance
If you have been working with MySQL for 6 years then stick with it!
You don't want to add the burden of learning another database as well as having to develop your application.
If you are unsure if MySQL is up to the job then run some tests. Write an app that runs multiple threads inserting 1M rows and see if your servers can handle it.
I'm guessing the brand of the database you choose will be less important than the performance of the platform (machines) it is running on.
There is no good or bad answer to this question. Basically it is as good as the DBA knowns to manage it.
If asking this question it would be wise to group a team of people well known with various systems to find out the best practice. To answer such a case, even more with very sensitive data, it is not just a simple solution which will do the trick. A thorough process of decision making is very important. Not only from a technical but also from a security and business side.
As per as think your database is large you can go with oracle.but the decision also depends on the expertise of people working with you and availability of resources.
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.
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 interested in both web resources and books. It´s a jungle out there, please give me a hand.
My goal is to learn the SQL language so I can query Sql Server databases within a couple of weeks.
I´ve got a programming background, and I know some basic stuff about relational databases, but almost nothing on how to use the SQL language.
Thanks to you ALL for all good tips! I will save this page as a starting point in my mission to learn SQL. Sadly enough it´s not possible to set more than one answer as "accepted"...
I don't normally go for the ' ... in 21 days' books but this online one seems reasonable: Teach Yourself SQL in 21 Days, Second Edition.
See Where can I find training/tutorials for SQL and T-SQL?
one of my favorite websites to get started with SQL is : SQLCourse
Good luck for your starting
This (w3schools) is always a nice place to start.
Try SQL Exercises
Perhaps You need to begin your own project, It is always recommended when learning something new that you fight with real problems.
http://www.databasejournal.com/ is one of good recurses,