sgeneris

17 ms·

61.
It Depends on the Dependencies: Normal Forms(dbdebunk.com)
1 points by sgeneris 10y ago|0 comments
62.
Don't Confuse Tables and Relations(dbdebunk.com)
2 points by sgeneris 10y ago|0 comments
63.
by sgeneris 10y ago
Pointless to anybody incapable of getting the point, of which there are too many.
64.
The Costly Illusion of Denormalization for Performance(allanalytics.com)
3 points by sgeneris 10y ago|0 comments
65.
by sgeneris 10y ago
No, correctness is not pedantry, except for the ignorant. The database facts are axioms and the facts in query results are theorems -- logical inferences from the axioms. If you don't understand that you have no clue what a relational
66.
by sgeneris 10y ago
First, you got it backwards: denormalization joins relations, normalization splits them; Second, if they share the same key, then it's not normalization, as the the split relations have distinct keys.
67.
by sgeneris 10y ago
No. I just thought the clarification was important.
68.
by sgeneris 10y ago
The basic issue is that derived data should not be included in base relations -- they belong in derived relations, such as views.
69.
by sgeneris 10y ago
There NO relationships whatsoever between normalization and the number of attributes, which are determined by the number of properties that entities have in the real world i.e., the conceptual model.
70.
by sgeneris 10y ago
What does it have to do with normalization?
71.
by sgeneris 10y ago
What do you know about the hurts of denormalization? Can you even specify what they are?
72.
by sgeneris 10y ago
No, I think you missed its point. I dare you to demonstrate that the "big data solutions" guarantee logical and semantic correctness the way true RDBMSs do. Without that, garbage in garbage out. But because those "solutions&q
73.
by sgeneris 10y ago
They are a fantasy only because users do not grasp the advantages of the RDM and confuse them with SQL, thus robbing vendors from any incentive to produce true RDBMSs. If users are so accepting of denormalization as a solution to performanc
74.
by sgeneris 10y ago
One more thing: As these comments demonstrate, there is almost exclusive focus on performance, but nobody considers the drawbacks (cost) of denormalization. Practitioners are oblivious to them.
75.
by sgeneris 10y ago
Normalization is not the same as full normalization. Full normalization does not decompose into relations with same key, because that means splitting one type of entities in two, that makes no logical sense. Rather, it splits non-5NF relati
76.
by sgeneris 10y ago
Tables are not relations. Relations have attributes, not columns, that represent entity properties. A R-table is a visual shorthand for a relation -- a way to visualize it on some physical medium (paper, screen) and the two should not be co
77.
by sgeneris 10y ago
SQL DBMS are not relational, so they don't really implement relations (they support bags and NULLs), not all their operations preserve closure, have weak support of relational constraints, of physical and logical independence, I could
78.
by sgeneris 10y ago
The sheer fact that much of the comments are about physical storage is an excellent validation of the article's claim that data professionals don't know and understand data fundamentals and the RDM.
79.
by sgeneris 10y ago
Yes, I would be surprised. Because, unlike most products which only require training to work with, true RDBMSs require knowledge of data and relational fundamentals and such is scarce today, because education has been replaced by sheer trai
80.
by sgeneris 10y ago
What does this have to do with the article?
81.
by sgeneris 10y ago
The argument in the paper is that data professionals -- 9ncluding yourself -- do not understand data fundamentals, for which reason they blame "poor performance" on the RDM. But RDM and normalization are purely LOGICAL and as the
82.
by sgeneris 10y ago
To a hammer ...
83.
by sgeneris 10y ago
If you are looking to solve performance "with a relational model" then you do not understand physical independence and the relational model. This is exactly what the article explains you should not do. You mean DBMSs, not databas
84.
Denormalization for Performance: Don't Blame the Relational Model(dbdebunk.com)
70 points by sgeneris 10y ago|62 comments
85.
Tables, Full Normalization and Business Rules(dbdebunk.com)
1 points by sgeneris 10y ago|0 comments
86.
Normalization, Further Normalization, Ease of Use, Integrity and Performance(dbdebunk.com)
1 points by sgeneris 10y ago|0 comments
87.
Brother, Spare Me the Paradigm(allanalytics.com)
1 points by sgeneris 10y ago|0 comments
88.
The Principle of Orthogonal Database Design Part I(dbdebunk.com)
1 points by sgeneris 10y ago|0 comments
89.
by sgeneris 10y ago
> Purists like to snear when they say this, but in point of fact its often true: its often more efficient to do things good enough for now and fix the things that turn out to need to fixing later (because the real pace of change often me
90.
by sgeneris 10y ago
Correction: I meant to say I made the practical implications of theory accessible via articles, seminars, books. The only way to claim they are not accessible is in the absence of basic foundation knowledge.

More ›