Prev: Possible to select a sample rows based on a column value?
Next: Query for merge column
From: --CELKO-- on 13 May 2010 10:32
Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, data types, etc. in
your schema are. If you know how, follow ISO-11179 data element naming
conventions and formatting rules. Temporal data should use ISO-8601
formats. Code should be in Standard SQL as much as possible and not
local dialect.

Sample data is also a good idea, along with clear specifications. It
is very hard to debug code when you do not let us see it. If you want
to learn how to ask a question on a Newsgroup, look at:
http://www.catb.org/~esr/faqs/smart-questions.html

If you don't know anything about RDBMS, then get a copy of the
simplest intro book I know --
http://www.amazon.com/Manga-Guide-Databases-Mana-Takahashi/dp/1593271905

If you want a simple introduction to thinking in sets instead of
sequential file structures,look at:
http://sqluniversity.net/media.php?mfile=ThinkingInSets.rm&pid=57

All of these things will help us do your homework for you in the
future.
From: Polaris431 on 13 May 2010 12:05
Sorry, but I disagree. Adding that really clutters up the posting.
There are many questions and answers posted here where no DDL is shown
and they are easy enough to understand. Some questions may require DDL
but I tend to believe that they are the exception rather than the
rule. A generic solution should be independent of DDL. Leave the
programmer to figure out the symantics of how the actual
implementation is to be done. I normally am looking for general
solutions and not some specific solution. Once a helping database
developer presents an idea, I usually take it from there and transform
it into a working solution. I think many developers will agree with me
on that.
From: --CELKO-- on 13 May 2010 13:48
>> Sorry, but I disagree. Adding that really clutters up the posting. There are many questions and answers posted here where no DDL is shown and they are easy enough to understand. <<

For the last few decades, skeleton DDL has been Netiquette in SQL
newsgroups and forums. The reason is that the DDL is more accurate and
compact than a long vague narrative.

>> Some questions may require DDL but I tend to believe that they are the exception rather than the rule. <<

Based on writing eight books, 900+ articles and two decades answering
SQL questions on line, I disagree :) A full schema is not required,
but even the most minimal DDL gives us at least data element names.

>> A generic solution should be independent of DDL. <<

No. The DDL gives the data elements and relationships. This is like
saying that you don't need to know what surface you are using (plane,
sphere, saddle) to do geometry. Let me give you a simple example with
some skeleton Nested Sets models:

CREATE TABLE Tree1
(node_name CHAR (15),
rgt INTEGER,
lft INTEGER);

CREATE TABLE Tree2
(node_name CHAR (15) PRIMARY KEY NOT NULL,
rgt INTEGER NOT NULL UNIQUE,
lft INTEGER NOT NULL UNIQUE);

CREATE TABLE Tree3
(node_name CHAR (15) NOT NULL,
rgt INTEGER NOT NULL UNIQUE,
lft INTEGER NOT NULL UNIQUE,
PRIMARY KEY (lft, rgt));

So much for a generic model! Tree1 is pretty much useless, but is
minimal. Tree2 gets the NULLs out of way, gives us some uniqueness.
Tree3 allows the same value to appear in many places; Tree2 does
not.

>> I usually take it from there and transform it into a working solution. I think many developers will agree with me on that. <<

That has let me earn a good living for 25 years, correcting code that
was written without a clear spec and no data integrity
From: Geoff Schaller on 14 May 2010 22:39
Ignore Celko. He says that to everyone where he doesn't understand the
question. The poor dear needs these crutches in order to give him enough
time to work through the question.

Don't worry - the rest of us will ask for this detail if we really think
it is essential...




"Polaris431" <johannblake(a)gmail.com> wrote in message
news:4c335446-9a7d-45af-8c88-ea288bc07fa3(a)l31g2000yqm.googlegroups.com:

> Sorry, but I disagree. Adding that really clutters up the posting.
> There are many questions and answers posted here where no DDL is shown
> and they are easy enough to understand. Some questions may require DDL
> but I tend to believe that they are the exception rather than the
> rule. A generic solution should be independent of DDL. Leave the
> programmer to figure out the symantics of how the actual
> implementation is to be done. I normally am looking for general
> solutions and not some specific solution. Once a helping database
> developer presents an idea, I usually take it from there and transform
> it into a working solution. I think many developers will agree with me
> on that.

From: Tony Rogerson on 15 May 2010 04:36
> That has let me earn a good living for 25 years, correcting code that
> was written without a clear spec and no data integrity

Interesting give away there --celko--

How long is it since you had regular work? A decade?

Your attitude, your arrogance and your in ability to accept when you are
wrong means you are mainly unemployable.

--ROGGIE--

"--CELKO--" <jcelko212(a)earthlink.net> wrote in message
news:f5deba13-4fc8-4e3a-a387-d71225391be3(a)k42g2000yqb.googlegroups.com...
>>> Sorry, but I disagree. Adding that really clutters up the posting.
>>> There are many questions and answers posted here where no DDL is shown
>>> and they are easy enough to understand. <<
>
> For the last few decades, skeleton DDL has been Netiquette in SQL
> newsgroups and forums. The reason is that the DDL is more accurate and
> compact than a long vague narrative.
>
>>> Some questions may require DDL but I tend to believe that they are the
>>> exception rather than the rule. <<
>
> Based on writing eight books, 900+ articles and two decades answering
> SQL questions on line, I disagree :) A full schema is not required,
> but even the most minimal DDL gives us at least data element names.
>
>>> A generic solution should be independent of DDL. <<
>
> No. The DDL gives the data elements and relationships. This is like
> saying that you don't need to know what surface you are using (plane,
> sphere, saddle) to do geometry. Let me give you a simple example with
> some skeleton Nested Sets models:
>
> CREATE TABLE Tree1
> (node_name CHAR (15),
> rgt INTEGER,
> lft INTEGER);
>
> CREATE TABLE Tree2
> (node_name CHAR (15) PRIMARY KEY NOT NULL,
> rgt INTEGER NOT NULL UNIQUE,
> lft INTEGER NOT NULL UNIQUE);
>
> CREATE TABLE Tree3
> (node_name CHAR (15) NOT NULL,
> rgt INTEGER NOT NULL UNIQUE,
> lft INTEGER NOT NULL UNIQUE,
> PRIMARY KEY (lft, rgt));
>
> So much for a generic model! Tree1 is pretty much useless, but is
> minimal. Tree2 gets the NULLs out of way, gives us some uniqueness.
> Tree3 allows the same value to appear in many places; Tree2 does
> not.
>
>>> I usually take it from there and transform it into a working solution. I
>>> think many developers will agree with me on that. <<
>
> That has let me earn a good living for 25 years, correcting code that
> was written without a clear spec and no data integrity

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Possible to select a sample rows based on a column value?
Next: Query for merge column