|
SQL for smarties by Joe Celko.
It's deceptively simple but lasts a long way.
People say nothing is impossible, but I do nothing every day.
|
|
|
|
|
If you are using SQL Server 2008 or later, I suggest you try T-SQL Fundamentals for Microsoft SQL Server by Itzik Ben-Gan.
|
|
|
|
|
I also read articles from http://www.sqlservercentral.com/[^] and they have a good Question of the Day feature that gets emailed to you daily so that you can test your knowledge etc.
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
You need to decide what start with. Do you want a general overview? To learn to code (T-SQL)? To learn how to be a DBA? Do you want a certificate?
I would go to a bookstore with a good computer section and look at the SQL books. As an example, have a question in mind, say for T-SQL, lookup data types. If you can understand what they say, that book would be high on the possible list.
|
|
|
|
|
Hi,
Check the following Books.
-- Book 1
Book Name : Beginning SQL Server 2008 for Developers From Novice to Professional Jul 2008
Authors : Louis Davidson, With Kevin Kline, Scott Klein, and Kurt Windisch
Publisher : APress
-- Book 2
Book Name : Pro-T-SQL-2008-Programmers-Guide-Experts-Voice-in-SQL-Server
Author : Michael Coles
Publisher : APress
Regards,
GVPrabu
|
|
|
|
|
Hi..
Recently i created Session State in my project, code is here..
<sessionState mode="SQLServer"
allowCustomSqlDatabase="true"
sqlConnectionString="Data Source=ADMIN-9F8C57749\SQLEXPRESS;Initial Catalog=kecbliss;Integrated Security=True"
timeout="60"
stateNetworkTimeout="60">
</sessionState>
the problem is day by day aspstatetempsessions table is becoming big
so my question is
1.can i delete previous days records from aspstatetempsessions?
2.How to achieve this without affecting to project ?
project details
front end ASP.NET
Back end MS SQL Server
|
|
|
|
|
|
hi all,
I am new database designer, and now i want to design database that can control avg cost and close stock.could you give me an idea? and please tell me the way to calculate avg cost every transaction(ex: sale,purchase,....) include Item avg cost and report. It is really difficult for new database designer like me. Thank in advanced.
|
|
|
|
|
|
I can't find the answer to this MySQL question in the documentation:
If I execute "LOCK TABLES" through an ODBC connection, and a different thread already holds a lock on the specific table, does the calling thread block until the lock is acquired, or does the call simply fail and return immediately?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I don't know the answer either. (I would assume it waits)
But check if you can use named locks[^] instead, then your application can name the lock and check if another instance have made a lock with the same name or not.
But watch out, there are a lot of pitfalls. So read the manual properly.
People say nothing is impossible, but I do nothing every day.
|
|
|
|
|
I need some help with an SQL query I’ve been asked to create.
Due to lack of communication, an update was done incorrectly and now needs to be fixed (surprise, surprise  ). Each employee has 5 Ben_Codes and the start date for all Ben_Codes needs to be equal to the start date of Ben_Code 1. The dates are not constant so for each employee I need to read Ben_Code 1 record to retrieve start_date and then update Ben_Codes 2 thru 5 with that start_date.
To this point I have done very basic updates using SQL Query and would appreciate any guidance you can provide!!
Emp_id, Ben_Code, start_date
99999 1 10/12/12
99999 2 01/12/13
99999 3 01/12/13
99999 4 01/12/13
99999 5 01/12/13
98989 1 9/15/2012
98989 2 01/12/13
98989 3 01/12/13
98989 4 01/12/13
98989 5 01/12/13
|
|
|
|
|
|
Yes, SQL Sever
Left that important bit of info out 
|
|
|
|
|
It would look something like this:
UPDATE
TableName tmp
SET
start_date = (SELECT start_date
FROM TableName
WHERE Emp_id = tmp.Emp_id AND
Ben_Code = 1)
WHERE
Ben_Code <> 1
|
|
|
|
|
Won't that rescan the table/index for each id?
|
|
|
|
|
PIEBALDconsult wrote: rescan the table/index
When fixing an error of this sort why would you care, if it was production code it would be an issue.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Just so I'm clear on what you guys are saying.....
It's not a huge concerned that it will rescan the table/index because this is a one production time fix and won't be running in production on a daily/weekly basis.....right?
|
|
|
|
|
Maybe not right now. But generally "good enough" isn't.
|
|
|
|
|
mrfalk wrote: one production time fix and won't be running in production
That was my point, I was just being bitchy at Piebald, something I do regularly.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Exactly. So is this how the responder writes production code when it matters?
Is this as much as the OP will learn? And he'll now write this way?
Perfect practice makes perfect. Do it the right way every time.
I see too much bad SQL being written. It should be nipped in its bud.
|
|
|
|
|
PIEBALDconsult wrote: So is this how the responder writes production code when it matters
Rubbish, fix the problem, fix it now and save the script, if it needs repeating then spend the time to make it elegant and efficient. Knowing that it is a kludge is more important than making a one off elegant.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
PIEBALDconsult wrote: Perfect practice makes perfect. Do it the right way every time.
Nope. Not in the real world.
The real world is about money. Getting it perfect every time takes time and thus costs money. In the real world it isn't possible to get it perfect and most of the time it will not have any significant impact on actual required production functionality. Thus the extra cost is lost revenue which will never be regained.
This of course isn't the same as saying that one can write poor code all the time. But rather one must learn to recognize that ones time is in fact valuable and thus one must prioritize what one spends time on. And since, again in the real world, one can not spend an infinite amount of time on everything, one must make compromises.
And one might specifically look at this thread as an example and note that without knowing about the actual business of which this artifact is a part one will not have any idea about specifics such as size of the table, usage statistics, allowed maintenance, etc. And when one looks at all possible tables in all possible businesses, on average it won't matter.
PIEBALDconsult wrote: I see too much bad SQL being written. It should be nipped in its bud.
Myself I see a lot of average code being written - it isn't specific to any language. Which is quite comforting since otherwise humans wouldn't be the ones writing it. If you are seeing a lot of poor SQL then maybe you need to start looking at a broader range of sources.
|
|
|
|
|
PIEBALDconsult wrote: Won't that rescan the table/index for each id?
Yes. You could load up a temp table (Emp_id, date) and then join the update to the temp table. It would lower the lookups by a 5th at the cost increasing the code complexity.
For something that will run once, I think the clarity of the correlated sub-query overrides any benefit on time. Of course, if we are talking gigabyte tables, I take it all back.
|
|
|
|
|
But of more import is that we are talking about a beginner who got this response from an expert* -- that's the big problem in my opinion. The beginner should be shown better code because he won't know any better otherwise. The poster, or other inexperienced developers who happen by, may think that the provided code is good for all situations.
* Anyone posting responses here assumes the role of expert with all the responsibilities thereof.
Michael Potter wrote: increasing the code complexity
I don't think my solution is any more complex than the other solution.
Michael Potter wrote: lower the lookups by a 5th
Correct me if I'm wrong (I could very well be), but my expectation of the first solution is n+1 lookups, whereas mine is 2 lookups. Granting that a modern database like SQL Server should work smarter than I would.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
