Database design question
sreedh...@gmail.com
columns in a table should be not null? In other words, if one column is
null then another column should not be null. Here is an example. Let's
say we have document and we need to specify permissions to the
document. The document has either individual or group level
permissions.
Document table
doc_id int primary,
doc_name varchar(50) not null
User table
user_id varchar(50) primary,
user_name varchar(100) not null
Group table
group_id int primary,
group_name varchar(50) not null
UserGroup table
user_group_id int primary,
group_id int not null,
user_id varchar(50) not null
DocumentPermission table
doc_id int,
group_id int,
user_id varchar(50)
So, either group_id or user_id should not be null in the
DocumentPermission table. Is there anyway we can have constraint like
this on the table? Is creating another group for that user the only
solution (Involves more administration)? Any help would be appreciated.
Thanks,
Sreedhar
Bob Badour
> I have a database design questions. How can we specify one of two
> columns in a table should be not null? In other words, if one column is
>
> null then another column should not be null.
The simple answer is to avoid null in the first place. Null will affect
the validity of everything it touches.
sreedh...@gmail.com
Thanks for your reply. How can we avoid nulls? If document has group
level permissions, then what will be the value for the user id (Just
blank)?
Michael Gaab
<sreedh...@gmail.com> wrote in message news:1151333970....@y41g2000cwy.googlegroups.com...
>I have a database design questions. How can we specify one of two
> columns in a table should be not null? In other words, if one column is
>
> null then another column should not be null.
My first thought is the following, either at the dbms level or
application level.
if( tableA.group_id == null)
{
tableB.user_id = IDGenerator();
}
Mike
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dan
For this model (I might have considered another), you might consider
the following. See if this helps in solving your problem:
CREATE TABLE docperm
(
doc_id INTEGER PRIMARY KEY
CONSTRAINT fk_docid_docperm REFERENCES document (doc_id),
group_id INTEGER NULL
CONSTRAINT fk_groupid_docperm REFERENCES group (group_id),
user_id VARCHAR2(50) NULL
CONSTRAINT fk_userid_docperm REFERENCES user(user_id),
/* Table level constraint */
CONSTRAINT ck_grouporuser_docperm
CHECK (((group_id IS NULL) AND (user_id IS NOT NULL))
OR ((group_id IS NOT NULL) AND (user_id IS NULL)))
);
This proposal also makes the assumption that a mutually exclusive
either-or condition is the desireable state. In other words, the
constraint won't allow one to reference both a group id and a document
id at the same time.
- Dan
sreedh...@gmail.com
Thanks Dan. I think this solution works, I will try to implement in
this way. Do you think of any alternative model to this? I appreciate
if you can share it.
Thanks,
Sreedhar
Bob Badour
I might suggest the Principle of Orthogonal Design (POOD) would give
some clues. I think you might get a few more from Fabian Pascal's
_Practical Issues in Database Management_ -- especially the sections on
sub-types.
kvnkr...@gmail.com
DocumentUserPermission table
doc_id int (PK),
user_id int (PK)
DocumentGroupPermission table
doc_id int (PK),
group_id int (PK)
DocumentPermission (view) :=
SELECT doc_id, user_id, group_id
FROM DocumentUserPermission
FULL OUTER JOIN
DocumentGroupPermission USING (doc_id);
kvnkr...@gmail.com
LOL - wrote that view in a hurry... I meant something more along the
lines of:
DocumentPermission (view) :=
SELECT doc_id, user_id, NULL group_id
FROM DocumentUserPermission
UNION
SELECT doc_id, NULL user_id, group_id
FROM DocumentGroupPermission
Jay Dee
What Bob said: design without NULLs.
In this case, I think "group permissions" and "user permissions"
should be in separate tables. And I suspect you have too many
attributes: is it really necessary, for example, to have an id
distinct from a name? (Can there *really* be two groups/users
with different id values and the same name? Your design allows
it.)
What's up with the user_group_id attribute?
From a different perspective: how is it that group_id and user_id
docperm are functionally dependent on doc_id?
Bob Stearns
This is a simple CHECK constraint:
alter table DocumentPermission
add constraint SomeValidUser
check (group_id is not null or user_id is not null)
Also you should have:
alter table DocumentPermission
add constraint doc_id_fk
foreign key (doc_id)
references document(doc_id)
and similar statements for group_id and user_id.
You also need a primary key for DocumentPermission. Unless there is at
most one user and/or one group permitted to each document, you will want
all 3 _id columns to be part of the primary key, which means they must
all be declared NOT NULL which, in turn, violates your design. You
probably need 2 permission tables, DocumentUserPermission and
DocumentGroupPermission.
kvnkr...@gmail.com
wouldn't be cleaner to use an OO solution. Just create a Document
class, and an abstract Viewer class extended by a Group class and a
User class. Each Document object can maintain a list of Viewers which
can view it. Each Viewer object can maintain a list of Documents which
it can view; each Group object can store a list of users that are a
part of it; applicable monadic properties for User objects is left as
an exercise.
I'll bet the application code would all but write itself. Plus, you
can encapsulate these properties and then expose Document methods of
canView(Viewer v) or Viewer methods of makeDocumentViewable(Document
d)... the cool thing is you can carefully change the underlying
implementation of such methods without breaking any code that calls
them.
Did I miss any other benefits of utilizing the OO paradigm? Are there
any cons?
Bob Badour
> In keeping with other discussions in cdt, I can't help but wonder if it
> wouldn't be cleaner to use an OO solution.
No, it wouldn't. A cleaner solution simply would avoid trying to state
facts about two mutually exclusive things in the same sentence. A
cleaner solution would state facts about group permissions separately
from facts about user permissions.
Just create a Document
> class, and an abstract Viewer class extended by a Group class and a
> User class.
Already you have introduced a useless entity or concept: viewer.
Each Document object can maintain a list of Viewers which
> can view it.
And yet another useless structural element: list.
Each Viewer object can maintain a list of Documents which
> it can view;
Yet another list to hack together something to try to compensate for the
symmetry you lost by doing something as stupid as using OO in the first
place.
each Group object can store a list of users that are a
> part of it;
Yet another list, but this was beyond the scope of the original example
so it isn't relevant to the comparison.
applicable monadic properties for User objects is left as
> an exercise.
The same would go for the monadic properties of any user-defined type in
the relational model. Since a monadic property is really just a relation
with degree 1, I find it amazing you would even bother suggesting that
direct support for relations of any degree is somehow less clean than
something supporting only relations of degree 1.
The relational model naturally deals with monadic properties as exactly
what they are. OO necessarily has to kludge anything trying to deal with
relations of other degrees.
> I'll bet the application code would all but write itself.
Meaningless bravado. Obviously, it won't.
Plus, you
> can encapsulate these properties and then expose Document methods of
> canView(Viewer v) or Viewer methods of makeDocumentViewable(Document
> d)...
Or you could have two relations and be done with it. You would
automatically get all of these predicates effortlessly using either the
algebra or the calculus, whichever your rdbms offers.
the cool thing is you can carefully change the underlying
> implementation of such methods without breaking any code that calls
> them.
But nowhere near as cool or as easily as changing a view or a physical
mapping for a relation.
> Did I miss any other benefits of utilizing the OO paradigm?
Other than announcing yourself as a self-aggrandizing ignorant, why
would you use the word 'paradigm' to mean an example, a verb declension,
or a world-view when better words exist for each of these? Since OO is a
computational model and none of the above, why would you use the word in
reference to OO at all?
Did you enumerate any benefits? I didn't see any.
Are there
> any cons?
Yes plenty. The more relevant question is: "Were there any pros?"
kvnkr...@gmail.com
> kvnkr...@gmail.com wrote:
> > In keeping with other discussions in cdt, I can't help but wonder if it
> > wouldn't be cleaner to use an OO solution.
>
> No, it wouldn't. A cleaner solution simply would avoid trying to state
> facts about two mutually exclusive things in the same sentence. A
> cleaner solution would state facts about group permissions separately
> from facts about user permissions.
>
>
> Just create a Document
> > class, and an abstract Viewer class extended by a Group class and a
> > User class.
>
> Already you have introduced a useless entity or concept: viewer.
>
>
Viewer has plenty of uses - it lets me create a list in each Document
object that is flexible enough to hold either a Group or a User. In
object orientation courses it is taught that this is a powerful feature
of the OO paradigm.
> Each Document object can maintain a list of Viewers which
> > can view it.
>
> And yet another useless structural element: list.
>
If I didn't use a list, what pray tell would I use to maintain the
Viewers that can view a document? Plus, in java, I can take advantage
of the fact that pre-defined ArrayList objects have an already-built
remove() method, so I can easily delete documents from the application,
and then use the remove() function on all Viewers' lists that contain
that document (naturally, I'd encapsulate this in a
removeDocumnet(Document d) method of the Viewer class).
Plus, I can make my Viewers' ArrayLists of ViewableDocuments implement
the Serializable interface, so I can store them to a disk in any format
I choose for permanence. And since they are encapsulated, with
probably less than a few hundred lines of carefully crafted code, I can
ensure that the action of renaming a document gets propogated to all
Viewers' lists that refer to that document, and that the data only gets
serialized when all such propogations are complete. And if this were
an application with many users, I could make my Viewers' Sieralizable
ArrayLists of ViewableDocuments synchronized, allowing them to be
maintained in a multi-threaded manner by sending asynchronous signals
between objects (this would probably need to be coded and tested
thoroughly by an experienced OO professional, of course). So we see
another benefit of OO paradigmation: scalability.
>
> Each Viewer object can maintain a list of Documents which
> > it can view;
>
> Yet another list to hack together something to try to compensate for the
> symmetry you lost by doing something as stupid as using OO in the first
> place.
>
Sigh. It's not hacking - it's OO paradigm computer programming, and
very skillful programming at that... see above for how this design
might need some real expertise for a production implementation (not
some cheap "hacker" that defines a couple of relational tables).
>
> each Group object can store a list of users that are a
> > part of it;
>
> Yet another list, but this was beyond the scope of the original example
> so it isn't relevant to the comparison.
>
>
Here, I'm just touting the extensible flexibilty of the OO paradigm.
Did I mention each User could maintain a list of the groups of which
they are a part? Of course, that was part of the exercise, but oh
well. This, too, could be serializable and synchronized for
consistency. The sky is the limit (and still we're probably only
talking about needing a small team of skilled programmers to maintain
what would probably be less than a thousand or two lines of code and
still ensure all the components work together seemlessly).
> applicable monadic properties for User objects is left as
> > an exercise.
>
> The same would go for the monadic properties of any user-defined type in
> the relational model. Since a monadic property is really just a relation
> with degree 1, I find it amazing you would even bother suggesting that
> direct support for relations of any degree is somehow less clean than
> something supporting only relations of degree 1.
Okay, forget I used the word monadic. (Sheesh, can't a OO
paradigmaniac use the right term every now and then?)
> The relational model naturally deals with monadic properties as exactly
> what they are. OO necessarily has to kludge anything trying to deal with
> relations of other degrees.
>
I'll bet there are a dozen OO experts who could back me up here: as
long as the kludge is encapsulated, it doesn't really matter - and if
the kludge doesn't work, then it can be changed without breaking
anything else that uses the interface. With rdbms, if you change the
tables, you might have to adjust the interface to match the underlying
model.
<snip more valid points>
> Other than announcing yourself as a self-aggrandizing ignorant
Mission accomplished. :-) Okay, end of the workday, I confess... I'm
not the OO paradigm fan the initial post may have led one to believe.
> Did you enumerate any benefits? I didn't see any.
>
I honest-to-god tried. I'm not sure I saw any, either. Any OO people
care to tell me where I went awry?
Bob Badour
> Bob Badour wrote:
>
>>kvnkr...@gmail.com wrote:
>>
>>>In keeping with other discussions in cdt, I can't help but wonder if it
>>>wouldn't be cleaner to use an OO solution.
>>
>>No, it wouldn't. A cleaner solution simply would avoid trying to state
>>facts about two mutually exclusive things in the same sentence. A
>>cleaner solution would state facts about group permissions separately
>>from facts about user permissions.
>>
>> Just create a Document
>>
>>>class, and an abstract Viewer class extended by a Group class and a
>>>User class.
>>
>>Already you have introduced a useless entity or concept: viewer.
>
> Viewer has plenty of uses
Not in the context of the problem given, it doesn't.
- it lets me create a list in each Document
> object that is flexible enough to hold either a Group or a User.
In other words, it is a superfluous entity created so that you could
introduce a superfluous structural element while destroying symmetry and
tossing away arguably the single most powerful formalism for managing
data. I have to admit that is a stunning feat!
Of stupidity.
In
> object orientation courses it is taught that this is a powerful feature
> of the OO paradigm.
What, exactly, is the feature you refer to? The need for superfluous
entities? The added structural complexity? A very low-level procedural
language for specifying how instead of what?
I suggest those teaching such nonsense should be exposed for the idiots
and scoundrels they are.
>> Each Document object can maintain a list of Viewers which
>>
>>>can view it.
>>
>>And yet another useless structural element: list.
>
> If I didn't use a list, what pray tell would I use to maintain the
> Viewers that can view a document?
You are asking me what structural element one should use to maintain a
completely useless entity? The answer is as simple as it is obvious:
nothing at all.
[longwinded java irrelevancies proving OO's inferiority snipped]
>> Each Viewer object can maintain a list of Documents which
>>
>>>it can view;
>>
>>Yet another list to hack together something to try to compensate for the
>>symmetry you lost by doing something as stupid as using OO in the first
>>place.
>
> Sigh. It's not hacking
Let's see. You started with something simple using a single structural
element and two simple instances of that element. You introduced useless
additional entities and a useless additional structural element that
broke symmetry. Having broken symmetry you compounded your error by
multiplying the instances of the useless structural element.
But you claim that's not hacking. If you are not "using kludges to
accomplish programming tasks that are ugly, inelegant, and inefficient",
what the hell do you think you are doing?
http://en.wikipedia.org/wiki/Hacker
- it's OO paradigm computer programming
Other than demonstrating that you are a self-aggrandizing ignorant, why
on earth would you use 'paradigm', which means variously an example, a
verb declension or a world-view, to refer to a computational model?
, and
> very skillful programming at that...
With all due respect, your self-assessment is fundamentally flawed and
suggests profound ignorance retards your ability to judge your own
skills. Skilled programmers reduce complexity while clarifying rather
than increase complexity while obfuscating.
[ignorant goad snipped]
>> each Group object can store a list of users that are a
>>
>>>part of it;
>>
>>Yet another list, but this was beyond the scope of the original example
>>so it isn't relevant to the comparison.
>
> Here, I'm just touting the extensible flexibilty of the OO paradigm.
Actually, you were demonstrating the idiotic habit of many OO proponents
of intentionally and proudly implementing unrequired features as if
doing so is anything other than introducing a bug.
> Did I mention each User could maintain a list of the groups of which
> they are a part?
Did I mention that the whole thing including the above question is
irrelevant to the original example? What part of 'irrelevant' do you not
understand?
Of course, that was part of the exercise, but oh
> well. This, too, could be serializable and synchronized for
> consistency.
Are you honestly suggesting that adding complexity and additional
processing is a benefit? Or that taking something directly represented
as part of a database and turning it into something one has to write
procedural side-effect code to store is a worthwhile endeavor?
Seriously. I have difficulty believing anyone could actually be that
stupid--in spite of the all too frequent evidence that some people that
stupid actually make careers as database experts.
The sky is the limit
Yes, I agree. There is no limit to how much complexity one can introduce
moving in the direction of increasing complexity. However, who would be
stupid enough to want to move in that direction?
(and still we're probably only
> talking about needing a small team of skilled programmers to maintain
> what would probably be less than a thousand or two lines of code and
> still ensure all the components work together seemlessly).
"Probably less than a thousand or two lines of code". Compared with two
data definition statements and two data manipulation statements. Wow.
That's incredible. You managed to take four lines of code and multiply
it by 250 to 500 without any discernible benefit from doing so. Bravo.
There should be an award for that. Something along the lines of a Darwin
award.
Who to name it in honor of though? Occam for multiplying entities beyond
all belief? Naw. It would have to be the anti-occam. Who did Occam spar
with back in the day? Or Mark Twain for noting that it is sometimes
better to remain silent than to remove all doubt? Or how about an 'Annie
Award' for posting evidence of being the world's oldest surviving
anencephalopath?
>> applicable monadic properties for User objects is left as
>>
>>>an exercise.
>>
>>The same would go for the monadic properties of any user-defined type in
>>the relational model. Since a monadic property is really just a relation
>>with degree 1, I find it amazing you would even bother suggesting that
>>direct support for relations of any degree is somehow less clean than
>>something supporting only relations of degree 1.
>
> Okay, forget I used the word monadic. (Sheesh, can't a OO
> paradigmaniac use the right term every now and then?)
I didn't have a problem with your use of the word. I asked some rather
pointed questions that you seem to want to evade. Perhaps you might try
answering them to yourself even if you don't want to answer them to the
newsgroup.
>>The relational model naturally deals with monadic properties as exactly
>>what they are. OO necessarily has to kludge anything trying to deal with
>>relations of other degrees.
>
> I'll bet there are a dozen OO experts who could back me up here: as
> long as the kludge is encapsulated, it doesn't really matter
It does matter when comparing with something that is: 1) simpler, 2)
requires no kludge, and 3) requires no extra step to separate concerns
or achieve information hiding. Regardless what a bunch of
self-aggrandizing ignorants might say to reinforce your idiotic ideas.
- and if
> the kludge doesn't work, then it can be changed without breaking
> anything else that uses the interface.
It's refreshing to see you admit the only possible significant outcome
of requiring the kludge in the first place: it might not work. Not
requiring the kludge in the first place obviates the possibility.
With rdbms, if you change the
> tables, you might have to adjust the interface to match the underlying
> model.
Here you demonstrate profound ignorance of fundamental concepts in the
relational model. I suggest you read up on views and logical independence.
[idiotic self-congratulation snipped]
>>Other than announcing yourself as a self-aggrandizing ignorant
>
> Mission accomplished. :-) Okay, end of the workday, I confess... I'm
> not the OO paradigm fan the initial post may have led one to believe.
But you are a self-aggrandizing ignorant who lacks intellectual honesty
and wastes people's time.
>>Did you enumerate any benefits? I didn't see any.
>
> I honest-to-god tried. I'm not sure I saw any, either. Any OO people
> care to tell me where I went awry?
Plonk.
Erwin
http://www.thethirdmanifesto.com/
See the item 'how to handle missing information without using nulls'
Erwin
Erwin
> some clues. I think you might get a few more from Fabian Pascal's
> _Practical Issues in Database Management_ -- especially the sections on
> sub-types.
POOD ????
I thought that the inventors of POOD considered nulls to be a violation
of 1NF. The first step in avoiding nulls is therefore applying 1NF. I
thought POOD was entirely orthogonal to the issue of normal forms.
kvnkr...@gmail.com
> But you are a self-aggrandizing ignorant who lacks intellectual honesty
> and wastes people's time.
The only one who wasted time here, as far as I can tell, is a certain
self-aggrandizing ignorant who is so single-mindedly focussed on
showcasing his intellectual prowess at identifying trees that he
actually revealed his ignorance of satirical prose by missing the
forest.
I mean, for crying out loud, didn't "Synchronizing the Viewers'
Serializable ArrayLists of Documents" even give you a clue - even a
moment of pause?
Anyway, presumably you'll write a quick insult and then killfile me for
this exchange. I don't care, inasmuch as it won't stop me from
gleaning useful insights from your well-informed contributions to the
newsgroup (for the satire-challeneged: that was not satire). But
before you do, might I recommend
1) reading posts as posts, and not a series of disconnected paragraphs,
before responding and
2) not always taking yourself so damned seriously?
Erwin
> Serializable ArrayLists of Documents" even give you a clue - even a
> moment of pause?
Brilliant. Just brilliant.
erk
> The only one who wasted time here, as far as I can tell, is a certain
> self-aggrandizing ignorant who is so single-mindedly focussed on
> showcasing his intellectual prowess at identifying trees that he
> actually revealed his ignorance of satirical prose by missing the
> forest.
>
> I mean, for crying out loud, didn't "Synchronizing the Viewers'
> Serializable ArrayLists of Documents" even give you a clue - even a
> moment of pause?
You had me too, you bastard, and I've been doing "Enterprise" Java for
6 years. Your parody is shockingly close to much of the O-O tutorials,
books, articles, etc.
:-) Good one. But you're really very close to the sad truth in O-O
land. On the app I'm working on now, instead of even collections, the
developers have written code to traverse arrays in nested loops,
looking for values in various attributes. Not even Maps.
Sigh.
- erk
Keith H Duggar
> I mean, for crying out loud, didn't "Synchronizing the
> Viewers' Serializable ArrayLists of Documents" even give
> you a clue - even a moment of pause?
Most intriguing. I will admit that this sentence (from your
original post) gave me the most pause:
> I'll bet the application code would all but write itself.
however I failed to conclude it was satire. As Erk pointed
out, the writing is so similar to what one actually reads in
OO literature and from OO /mentors/ and such that it could
honestly go either way. And given the recent activity in
c.d.t it would not be surprising had this been a genuine
"solution" :-)
-- Keith -- Fraud 6
Bob Badour
> kvnkr...@gmail.com wrote:
>
>>The only one who wasted time here, as far as I can tell, is a certain
>>self-aggrandizing ignorant who is so single-mindedly focussed on
>>showcasing his intellectual prowess at identifying trees that he
>>actually revealed his ignorance of satirical prose by missing the
>>forest.
>>
>>I mean, for crying out loud, didn't "Synchronizing the Viewers'
>>Serializable ArrayLists of Documents" even give you a clue - even a
>>moment of pause?
OO is mostly noise and meaningless gibberish. What was significantly
different in what kevin wrote?
kvnkr...@gmail.com
All, my apologies. After reading these responses, I read the posts I
made in a new light, and realized that coming from a new user to a
newsgroup - and with a good probability of said user being a OO
enthusiast from the c.o. group - the parody was not nearly as overt as
I intended.
In lieu of that, I truly am sorry for any time anyone may have spent
formulating, composing or posting legitimate replies to the posts.
Yes, that includes Bob.
mAsterdam
a nice wake-up call. I admit, that before the joke
was explained, I just thought
Aloha Kakuikanu
> In keeping with other discussions in cdt, I can't help but wonder if it
> wouldn't be cleaner to use an OO solution. Just create a Document
> class, and an abstract Viewer class extended by a Group class and a
> User class. Each Document object can maintain a list of Viewers which
> can view it. Each Viewer object can maintain a list of Documents which
> it can view; each Group object can store a list of users that are a
> part of it; applicable monadic properties for User objects is left as
> an exercise.
>
> I'll bet the application code would all but write itself. Plus, you
> can encapsulate these properties and then expose Document methods of
> canView(Viewer v) or Viewer methods of makeDocumentViewable(Document
> d)... the cool thing is you can carefully change the underlying
> implementation of such methods without breaking any code that calls
> them.
I must admit I feel like humor impared too. For future can you please
make it little bit more obvious? For example, introduce a
DocumentManager class. Then, Manager'sManager. Then argue that
DocumentPermission is unnecessary and can be handled transparrently via
magic object access keywords ("private", "protected").
David Fetter
> I have a database design questions. How can we specify one of two
> columns in a table should be not null? In other words, if one
> column is null then another column should not be null.
In general, you should be able to use a CHECK constraint, something
like this:
CREATE TABLE foo (
bar INTEGER,
baz INTEGER,
CHECK (
(CASE WHEN bar IS NULL THEN 0 ELSE 1 END) +
(CASE WHEN baz IS NULL THEN 0 ELSE 1 END)
= 1
)
);
I can't really speak to the particular design, and very likely
somebody will take me to task for failure to scream about how NULLs
don't belong in any design. ;)
Cheers,
D
--
David Fetter <da...@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
Kernighan
David Cressey
<kvnkr...@gmail.com> wrote in message
news:1151437191.3...@p79g2000cwp.googlegroups.com...
> All, my apologies. After reading these responses, I read the posts I
> made in a new light, and realized that coming from a new user to a
> newsgroup - and with a good probability of said user being a OO
> enthusiast from the c.o. group - the parody was not nearly as overt as
> I intended.
>
> In lieu of that, I truly am sorry for any time anyone may have spent
> formulating, composing or posting legitimate replies to the posts.
> Yes, that includes Bob.
>
You got me. I thought it was serious. That probably means that it's good
satire.
I recently picked up and read a windows oriented "Hello World" program in
C++ from an old distribution of Turbo C++.
It reads like satire. But I think they were serious.
I spend a lot of time in c.d.t. trying to understand ideas that I think are
profoundly wrong. Perhaps, too much time.
We've had people come in here and seriously suggest that we revert to the
state of data modeling in 1969, and pick it up from there.
One person maintained, for years, that with a suitably clever access
langugage all you need is character based data types, structured into files
made up of records, records made up of fields, and fields made up of lists
of values. She maintained that position for years in here. If that was
satire, it was damned good satire.
And I can't tell you the number of people who have come into c.d.t. and
suggested that the best design for relations is to put all the data into one
big table.
So I forgive myself for having been taken. And I forgive you for being too
subtle for this medium.