Talk:SQL - Revision history

JaroslavTulach at 12:35, 26 February 2011

JaroslavTulach — Sat, 26 Feb 2011 12:35:59 GMT

←Older revision		Revision as of 12:35, 26 February 2011
Line 95:		Line 95:
	--[http://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844/ref=dp_ob_title_bk softwarevisualization] 03:20, 24 February 2011 (CET)		--[http://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844/ref=dp_ob_title_bk softwarevisualization] 03:20, 24 February 2011 (CET)
	</div>		</div>
		+
		+	I don't feel real need to read book about [[SQL]] now (I still have three [[wikipedia:Fyodor_Dostoyevsky\|Dostojevkij]]'s books to go through), but I found:
		+	http://broadcast.oreilly.com/2009/07/relational-databases-as-realit.html
		+	The article seems to indicate that Date explains [[SQL]] from a point of its [[wikipedia:Relational algebra\|relational algebra]] roots. I shall be well aware these roots, my profesor [http://www.ksi.mff.cuni.cz/osoba.php?osoba=8#publikace Jaroslav Pokorný] started to explain [[wikipedia:Relational algebra\|the algebra]] to us and only after few months (when we knew concepts of the [[wikipedia:Relational algebra\|relational algebra]] by heart) he mentioned how to realize the same concepts using [[SQL]]. I have forgotten most of it already, but I understand the value of the mathematical model behind relational database. All I am saying is that often we pay too big price for the comfort of few joins and selects and that simple solution may be more effective. Of course, if you really value your data, [[Oracle]]'s database is the best place to store them ;-)
		+
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 12:35, 26 February 2011 (UTC)

71.194.199.148: Comment provided by softwarevisualization - via ArticleComments extension

71.194.199.148 — Thu, 24 Feb 2011 02:20:47 GMT

Comment provided by softwarevisualization - via ArticleComments extension

←Older revision		Revision as of 02:20, 24 February 2011
Line 75:		Line 75:

	--Jiri Tulach 12:45, 6 September 2010 (CEST)		--Jiri Tulach 12:45, 6 September 2010 (CEST)
		+	== softwarevisualization said ... ==
		+
		+	<div class='commentBlock'>
		+	I would say to anyone having doubts about eh relational model, not to say any particular SQL product, that they look at Chris Date's work, including his innumerable interviews and articles in which he takes on any and all complaints regarding the relational model.
		+
		+	Honestly, I've read a lot of his back and forth with a wide variety of opponents and I haven't ever judged him to be the loser in an argument.
		+
		+	Of all the books he's written over the years, The book he would tell you to read at this point in time (2011) is probably his Intro. to DB systems : (and at sig)
		+
		+	http://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844/ref=dp_ob_title_bk
		+
		+
		+	I have no particular love for SQL, it's one of those technologies someone else can do better, and I let them. But the relational model which underlies all SQL products is not something whose limitations were are suddenly discovering- quite the opposite, it's the solution to those limitations.
		+
		+	As Date likes to point out, hierarchical models of data representation, even if that data is itself hierarchical, are a path we've been down before and the relational model is the solution to the intractable problems we encountered there. As Sanatayan said, those who dont' know history are doomed to repeat it and repeating history is what we're doing when we embrace things like OODBMS etc. etc. as models of representation.
		+
		+	But Date explains this so much better. If I thought I had a legitimate gripe against the relational model, not to say a database product, I would first check to see what Date had to say lest I leave myself open to eventually being exposed as someone who really does't know have a firm grasp on the subject :(
		+
		+	--[http://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844/ref=dp_ob_title_bk softwarevisualization] 03:20, 24 February 2011 (CET)
		+	</div>

JaroslavTulach at 09:27, 10 September 2010

JaroslavTulach — Fri, 10 Sep 2010 09:27:53 GMT

←Older revision		Revision as of 09:27, 10 September 2010
Line 71:		Line 71:

	--[[User:JaroslavTulach\|JaroslavTulach]] 19:37, 3 September 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 19:37, 3 September 2010 (UTC)
-	~~=== Jiri Tulach said ... ===~~

-	~~<div class='commentBlock'>~~
	As a Oracle employee you should know what is the best solution ;-).		As a Oracle employee you should know what is the best solution ;-).

	--Jiri Tulach 12:45, 6 September 2010 (CEST)		--Jiri Tulach 12:45, 6 September 2010 (CEST)
-	~~</div>~~

JaroslavTulach at 09:27, 10 September 2010

JaroslavTulach — Fri, 10 Sep 2010 09:27:25 GMT

←Older revision		Revision as of 09:27, 10 September 2010
Line 71:		Line 71:

	--[[User:JaroslavTulach\|JaroslavTulach]] 19:37, 3 September 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 19:37, 3 September 2010 (UTC)
-	== Jiri Tulach said ... ==	+	=== Jiri Tulach said ... ===

	<div class='commentBlock'>		<div class='commentBlock'>

213.180.34.38: Comment provided by Jiri Tulach - via ArticleComments extension

213.180.34.38 — Mon, 06 Sep 2010 10:45:13 GMT

Comment provided by Jiri Tulach - via ArticleComments extension

←Older revision		Revision as of 10:45, 6 September 2010
Line 71:		Line 71:

	--[[User:JaroslavTulach\|JaroslavTulach]] 19:37, 3 September 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 19:37, 3 September 2010 (UTC)
		+	== Jiri Tulach said ... ==
		+
		+	<div class='commentBlock'>
		+	As a Oracle employee you should know what is the best solution ;-).
		+
		+	--Jiri Tulach 12:45, 6 September 2010 (CEST)
		+	</div>

JaroslavTulach at 20:23, 3 September 2010

JaroslavTulach — Fri, 03 Sep 2010 20:23:57 GMT

←Older revision		Revision as of 20:23, 3 September 2010
Line 36:		Line 36:
	--SMJ 07:51, 1 September 2010 (CEST)		--SMJ 07:51, 1 September 2010 (CEST)
	</div>		</div>
-	== Dan Sheppard said ... ==	+	=== Dan Sheppard said ... ===

	<div class='commentBlock'>		<div class='commentBlock'>
Line 57:		Line 57:

	--[[User:JaroslavTulach\|JaroslavTulach]] 17:02, 1 September 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 17:02, 1 September 2010 (UTC)
-	== Jiri Tulach said ... ==	+
		+	=== Jiri Tulach said ... ===

	<div class='commentBlock'>		<div class='commentBlock'>

JaroslavTulach at 19:37, 3 September 2010

JaroslavTulach — Fri, 03 Sep 2010 19:37:56 GMT

←Older revision		Revision as of 19:37, 3 September 2010
Line 64:		Line 64:
	--Jiri Tulach 23:19, 2 September 2010 (CEST)		--Jiri Tulach 23:19, 2 September 2010 (CEST)
	</div>		</div>
		+
		+	Čau Jirko. As I am [[Oracle]] employee since 1st Sep, 2010, and I was well educated during recent days' presentations I know that [[Oracle]] [[SQL]] database is perfectly horizontally scalable (compared to any competition). So you are right, it is a question of a good database. So guys, don't wait and buy one from my employer!
		+
		+	Encode everything into a columns and rows. Perform an [[SQL]] query which runs on indexes like crazy. Buy good database to make it effective. Be [[clueless]]! Sure, you could consider storing data in plain files are read each in less then 10ms and index this by [[Lucene]]. This solution could fit in 64MB machine (including [[Java]] runtime). But where would be the reference integrity? Where would be transaction isolation?
		+
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 19:37, 3 September 2010 (UTC)

82.150.163.34: Comment provided by Jiri Tulach - via ArticleComments extension

82.150.163.34 — Thu, 02 Sep 2010 21:19:36 GMT

Comment provided by Jiri Tulach - via ArticleComments extension

←Older revision		Revision as of 21:19, 2 September 2010
Line 57:		Line 57:

	--[[User:JaroslavTulach\|JaroslavTulach]] 17:02, 1 September 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 17:02, 1 September 2010 (UTC)
		+	== Jiri Tulach said ... ==
		+
		+	<div class='commentBlock'>
		+	It's all about data size and performance. There are many options. You can infuence it by DB architecture, selection of SQL machine, caching techniques, HW sizing and replication. NoSQL is also option but it's just a different data structure and you can also stuck in the similar troubles as in SQL. Also NoSQL is often used because many SQL machines are not easily scalable.
		+
		+	--Jiri Tulach 23:19, 2 September 2010 (CEST)
		+	</div>

JaroslavTulach at 17:02, 1 September 2010

JaroslavTulach — Wed, 01 Sep 2010 17:02:46 GMT

←Older revision		Revision as of 17:02, 1 September 2010
Line 14:		Line 14:
	A mature or long running system normally indicates these problems you speak of.		A mature or long running system normally indicates these problems you speak of.

-	No use crapping about it; hence the ~~oppertunity~~ presents itself to introduce similar wrappers for whatever database bugzilla runs on, maybe MySQL.	+	No use crapping about it; hence the opportunity presents itself to introduce similar wrappers for whatever database bugzilla runs on, maybe MySQL.

-	I'd think hibernate to be a worthy candidate if they don't have it already.... !!!	+	I'd think [[hibernate]] to be a worthy candidate if they don't have it already.... !!!

	--. 07:24, 1 September 2010 (CEST)		--. 07:24, 1 September 2010 (CEST)
	</div>		</div>
		+
		+	I can't imagine use of [[hibernate]] on any other than relational (aka [[SQL]]) database.
		+
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 17:02, 1 September 2010 (UTC)

	=== SMJ said ... ===		=== SMJ said ... ===
Line 39:		Line 43:
	The author is not some novice. He wrote an application that is downloaded some 8 million times a year by fellow developers! His experience and ability is unquestionable!		The author is not some novice. He wrote an application that is downloaded some 8 million times a year by fellow developers! His experience and ability is unquestionable!

-	Complete nonsense? No! SQL is a language and the author says so. SQL is however constructed around assumptions about how the data is stored (tables of data) and manipulated (set relation semantics). This provides a general tool and yes performance can be improved in a variety of ways. There is however no getting away from the fact than this arrangement of data is not always what is required and supporting SQL can give an unnecessary overhead. To quote the wikipedia page on NoSQL (which includes reference link to research) "Typical modern relational databases have shown poor performance on data-intensive applications including indexing a large number of documents, serving pages on high-traffic websites and delivering streaming media."... and so Google and Amazon store some of their data in non-relational databases with no SQL.	+	Complete nonsense? No! [[SQL]] is a language and the author says so. [[SQL]] is however constructed around assumptions about how the data is stored (tables of data) and manipulated (set relation semantics). This provides a general tool and yes performance can be improved in a variety of ways. There is however no getting away from the fact than this arrangement of data is not always what is required and supporting SQL can give an unnecessary overhead. To quote the wikipedia page on [[wikipedia:NoSQL\|NoSQL]] (which includes reference link to research) "Typical modern relational databases have shown poor performance on data-intensive applications including indexing a large number of documents, serving pages on high-traffic websites and delivering streaming media."... and so Google and Amazon store some of their data in non-relational databases with no SQL.

	As one other example it should be noted that chess games are held in bespoke non-SQL databases by the various chess programs. Chess databases do not store games as tables of data but as trees so that games can be efficiently navigated through and queried. Queries are made against the characteristics of the position and not just against a set of data.		As one other example it should be noted that chess games are held in bespoke non-SQL databases by the various chess programs. Chess databases do not store games as tables of data but as trees so that games can be efficiently navigated through and queried. Queries are made against the characteristics of the position and not just against a set of data.
Line 47:		Line 51:
	--Dan Sheppard 15:32, 1 September 2010 (CEST)		--Dan Sheppard 15:32, 1 September 2010 (CEST)
	</div>		</div>
		+
		+	Thanks guys for your comments. At University we started to learn [[wikipedia:relational algebra\|relational algebra]] and only then mapped its concepts into [[SQL]]. As there is almost 1:1 mapping between [[SQL]] and the [[wikipedia:relational algebra\|relational algebra]] (well, there is no ''LIKE'' construct and sorting of results is probably impossible), as [[wikipedia:relational algebra\|relational algebra]] is applicable only to relational databases, it all forms one big braid for me. Thus I call it all [[SQL]]. [[SQL]] databases, [[SQL]] [[DSL]], etc.
		+
		+	Btw. I was in rush to publish the [[SQL]] blog before Sep 1, 2010 and as such I did not re-read it properly. I am not saying the grammar would be perfect if I did, but there might have been slightly less obvious typos.
		+
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 17:02, 1 September 2010 (UTC)

80.177.219.26: Comment provided by Dan Sheppard - via ArticleComments extension

80.177.219.26 — Wed, 01 Sep 2010 13:32:43 GMT

Comment provided by Dan Sheppard - via ArticleComments extension

←Older revision		Revision as of 13:32, 1 September 2010
Line 31:		Line 31:

	--SMJ 07:51, 1 September 2010 (CEST)		--SMJ 07:51, 1 September 2010 (CEST)
		+	</div>
		+	== Dan Sheppard said ... ==
		+
		+	<div class='commentBlock'>
		+	I feel the need to respond to SMJ's.
		+
		+	The author is not some novice. He wrote an application that is downloaded some 8 million times a year by fellow developers! His experience and ability is unquestionable!
		+
		+	Complete nonsense? No! SQL is a language and the author says so. SQL is however constructed around assumptions about how the data is stored (tables of data) and manipulated (set relation semantics). This provides a general tool and yes performance can be improved in a variety of ways. There is however no getting away from the fact than this arrangement of data is not always what is required and supporting SQL can give an unnecessary overhead. To quote the wikipedia page on NoSQL (which includes reference link to research) "Typical modern relational databases have shown poor performance on data-intensive applications including indexing a large number of documents, serving pages on high-traffic websites and delivering streaming media."... and so Google and Amazon store some of their data in non-relational databases with no SQL.
		+
		+	As one other example it should be noted that chess games are held in bespoke non-SQL databases by the various chess programs. Chess databases do not store games as tables of data but as trees so that games can be efficiently navigated through and queried. Queries are made against the characteristics of the position and not just against a set of data.
		+
		+	Grammatically deficient? I'm sure your Czech is much worse than his English! I've certainly seen worse grammar than in this article. SMJ's wasn't perfect either: "It is right in the name Q is for query!" is missing punctuation between the 2 clauses!
		+
		+	--Dan Sheppard 15:32, 1 September 2010 (CEST)
	</div>		</div>