Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I read both the Microsoft Docs and this article. I however can't seem to find where I could only use cursors and not something else so I'd appreciate If someone could give a few examples.
I also came across this answer on stackoverflow and Jeffrey Hantin gave me more doubts.
Imagine a command which must get a literal parameter like BCP.
Try to read 100 XML files living somewhere on your disc and you have their path and filenames in a table.
In this case you will create the statements dynamically and use EXEC to run each separately.
This might be any kind of loop, but a CURSOR seems to be the closest.
The general answer is: Avoid loops, most needs can be solved without using a loop. With SQL one should use set-based approaches over procedural approaches.
I find I only ever use cursors for administration tasks. For example I have a script that runs through my high activity large tables. That rebuilds the indexes overnight that query itself is pretty set based. However I have multiple customer databases on the same box with the same structure. I would wrap the maintenance script in a cursor that pulls out the database names and loops through them.
I find this reduces the amount of work I have to do, as the list of databases to work through is generated by the cursor. If I add customers/ delete customers the maintenance is unaffected. If I run up a new box I can add that as part of the set up process so when I get round to setting up a customer system on the new box it is automatically being maintained.
Here is a sample of somebody using the same concept to backup all of their databases. https://www.mssqltips.com/sqlservertip/1070/simple-script-to-backup-all-sql-server-databases/
Same benefits that I've mentioned in that it is defined once and whether you add remove or move databases they are already automatically in the backup plan
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
My question is more for practice than a debug issue.
At work, we use a Java-JEE/Oracle solution and the least I can say is we need to perform SQL query, anticipate SQL performances, handle SQL issues like foreign key or orphan line and so on.
So from my point of view, doing SQL is very important. For a new project, we are looking to implement the solution in Ruby on Rails. But most of the tutorial and code I see, seems to nest every Postgres SQL code under Active Record implementation. I have already experienced some similar issue with the Java Hibernate framework and its "no need SQL code." Some production issues were madness, the generated hidden SQL query were not easy to read and there is no deal with index or foreign key.
Any one can tell me what risk we have to use only Active Record ?
What is the proper process to avoid most common Ruby/SQL interface issues ?
When did you need to open your SQL console et type some SQL query ?
Share a little bit its experience on these points.
If you have any relevant link dealing with this topic.
Thank you very much !
You can still use sql.
Either low level, where you receive an array of arrays of values.
Or a little more high level, so you receive objects, with methods like find_by_sql.
Or by providing only sql-fragments, for example for the where-clause.
How often you need sql depends on your use case.
Ruby is about objects, sql is about tables. ActiveRecord handles objects as rows in a table. That works most of the time quite good. All simple queries are handles automatically. You can describe relations between objects, and even joins to retrieve these relations are handled.
For queries with several joins or group_by, it is sometimes easier to write the sql instead of instructing activerecord to build the sql you have in mind.
Also you need to have an eye on what sql is generated, as it is easy to write code that is inefficient, for example by generating many small sql statements.
The official Rails guides about "models" are the most important resource. From sql perspective you should have a look at "Active Record Query Interface"
http://guides.rubyonrails.org/active_record_querying.html
I also done a presentation about rails database optimisation, but it for rails 3.2 and a little out of date (joins are now better handled)
http://meier-online.com/en/2012/08/presentation-rails-database/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Introduction:
So, I have an interview tomorrow and I'm trying to review SQL and databases. The job posting says that they want someone with:
Experience with database design and development
Strong knowledge of SQL
Experience with SQL Server and/or Postgres
I've read through Questions every good database SQL developer should be able to answer, and a bunch of questions tagged with SQL and interview-questions. So I realize that I need to know about SELECT, JOIN and WHERE.
Questions:
What are essential SQL, Postgres and database concepts that I need to know in order to do well in the interview?
What do I need to know about transaction and normalization?
What are some general ways to optimize slow queries?
Should I learn about the functions, keywords or both?
It depends on how much of the role is based around database development and design. For your SQL syntax, you should also understand the difference between the types of joins, and be able to use GROUP BY, ORDER BY, HAVING as well as the aggregate functions that can be used in conjunction with them.
In terms of performance monitoring, I would be looking at execeution plans (not sure about the Postgres equivalent) and how they can provide tips on increasing performance, as well as using SQL Profiler to see what instructions the server is executing in real time.
Transactions can be useful for rolling back, well, transactions (stored procs, ad-hoc queries etc.) that require queries to complete in a certain way to maintain data consistency. Some people (myself included) have a practice of placing any statements that make any changes to data into a transaction that automatically rolls back (BEGIN TRAN ... ROLLBACK TRAN) to check that the correct amount of data is manipulated before pushing changes to a live server. Have a look at the ACID model - Atomicity, Consistency, Isolation, Durability.
Normalization is something that can take a little time to go through, but just know and partially understand up to 3rd form normalization and that will get you started.
Optimisation can be a huge topic. Just remember to try and do things like UPDATE using set based queries, rather than row based (updating in a WHILE loop is an example of row based updating, but it CAN have its uses).
I hope this helps a little.
Besides the basics of sql syntax, which you listed, you should know some things about query performance. What are some common causes of slow queries and what are the remedies for those, and how can you evaluate the performance of a query.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I don't even want to think about how many man hours have been spent writing the same queries to join over the exact same tables at my company.
When I first started at my job I identified this as an inefficiency and started writing views in a separate schema for the sole purpose of developer convenience.
My boss didn't like this very much and recommended I start committing my common queries to source control in a separate folder from the production SQL. This makes sense because some scripts require parameters and not all are read only.
What is a Common Query?
Script used to diagnose certain problems
Script to view relationships between several tables (doing multiple joins)
Script that we don't want in a stored procedure because it is often tweaked to diagnose the issue of the day
Issues I want to Address
Discoverability, queries will be rewritten if nobody can find them
IDE integration, want to be able to easily view queries in IDE. I've tried the SQL Server Solutions but they really suck because they lock you into only working on that set of files.
I was wondering how all the pro's out there share their common SQL queries.
Thanks
Seems like the op wants to know how to get the word out to the team about useful SQL that others can/should use so not to recreate.
How I have done this in the past is through two ways:
Create a team web wiki page that
details the SQL with examples of how
it is used.
Email the team when new SQL is
created that should be shared.
Of course, we always include the SQL code in version control, just the wiki and email are use in the "getting word out there" part.
If it is something that I would call "common" I would probably create a stored procedure that the folks with necessary permissions can run.
If the stored procedure route won't work well for your team, then the other option is to create a view. Creating a view comes with unique challenges though such as ensuring that everyone running the view has select permissions on all of the tables in the view as well.
Outside of storing the scripts in source control of some kind, maybe storing them on a Share Point site or a network file share would work OK for your team. The real challenge that you will have in sharing scripts is that people have different ways to identify what they are looking for. A wiki type of site that allows tagging the different types of things the queries do would be useful.
You create a view.
Lots of ways to do this (including some that you've mentioned already):
Table-Valued User Defined Functions
Stored Procedures
Views
Source Control
Formal, shared Data Access Layer for client code
Views are the right way to handle this sort of thing. Or, in some cases, a stored procedure.
But there's no rule that says you can't also store the DDL for a View or a Stored Procedure in source control.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I always thought an SQL compiler would break but apparently nesing can nearly be infinite. Is this code to be trashed immediately or is there some glimmer of hope that something like this can function?
This query doesn't really belong to me so I cannot post it... However let's just pretend it is this one:
[SELECT /*+ NOPARALLEL bypass_recursive_check */
SP_ALIAS_190,
((CASE SP_ALIAS_191
WHEN 1
THEN 'PROVIDER::ALL_PROV::'
WHEN 0]
Clearly, you've never seen the SQL that comes out of the Sharepoint DAL.
If the query is generated by a tool (or by code), then it may be relatively simple to maintain (in the sense that the query generation code may in fact be well written and maintainable)
I ran into a problem similar to this recently and I came to a decision by considering a couple of things:
How long is this going to take to maintain vs. rewrite?
How critical is this? There may be a lot of logic that may be difficult to unravel and the value in the fact that "it works" exceeds the value from an immediate rewrite.
And of course, there was the political decision management had to make concerning risking explaining why something that was recently created would have to be rewritten.
In the end (for me), find + replace was my friend.
Refactor it using the WITH statement.
Add lots and lots and lots of comments.
If you break it into pieces that can be managed, you stand a much better chance.
If it contains allot of nesting I would say no.
Like any code no matter what language, you should only look at re-writting it because you can make it more efficient or easier to understand.
Based on my experiance I have been able to reduce badly written SQL 4 to 5 times its size and many times its performance because the origonal auther really had no idea.
If you think that's bad, you should see Industrial Logic's sample video on code smells: Technical Debt. Definitely not autogenerated.
Is it possible to maintain a 43 page function, say, in C#? The answer is obvious ;). I just cannot imagine this. If I were you I would break it into smaller parts.
Two things:
Will only machines ever need to read this SQL?
Are you stuck with the underlying schema?
If you have a 43 page query and you answered yes to the first two questions, welcome to SharePoint development
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Here's my situation. I've noticed that code gets harder to maintain when you keep embedding queries in every function that will use them. Some queries tend to grow very fast and tend to lose readability after concatenating every line. Another issue that comes with all of the concatenation is when you must test a specific query and paste it. You are forced to remove all of the " that held your query string together.
So my question is, what methods are being used to separate queries from the code? I have tried searching but it doesn't look like it's the right thing because i'm not finding anything relevant.
I'd like to note that views and stored procedure are not possible since my queries fetch data from a production database.
Thank you.
If you follow an MVC pattern, then your queries should be all in the model - i.e. the objects representing actual data.
If not, then you could just put all your repetitive queries in script files, including only those needed in each request.
However, concatenating and that kind of stuff is hard to get rid of; that's why programmers exist :)
These two words will be your best friend: Stored Procedure
I avoid this problem by wrapping queries in classes that represent the entities stored in the table. So the accounts table has an Account object. It'll have an insert/update/delete query.
I've seen places where the query is stored in a file and templates are used to replace parts of the query.
Java had something called SQLJ - don't know if it ever took off.
LINQ might provide some way around this as an issue too.
Risking being accused of not answering the question, my suggestion to you would be simply don't. Use an O/RM of your choice and you'll see this problem disappear in no time.
I usually create a data class that represents the data requirements for objects that are represented in the database. So if I have a customer class, then I create a customerData class as well that houses all the data access logic in them. This keeps data logic out of your entity classes. You would add all you CRUD methods here as well as custom data methods.
Youc an also use Stored Proceedures or an ORM tool depending on your language.
The main key is to get your data logic away from your business and entity logic.
I use stored procedures in my production environment, and we process the rows too...