Re: Sensible and NonsenSQL Aspects of the NoSQL Hoopla

Am Sonntag, 25. August 2013 15:38:37 UTC+2 schrieb Eric:

>
> I know what cursors and indexes are, but it is "Not only SQL" that is
>
> confusing. They are not part of relational theory, but they are part of
>
> SQL.
>
I use SQL as a "relational query language". "Nonrelational" Querying (special case handling, short circuit boolean evaluation) is easy scanning cursors from begin to end.

>
> The logical model is the set of relations and constraints that you
>
> define to represent as much of a set of real life structures as you wish
>
> to store and manipulate. The physical model is how your database
>
> software organises the data for efficient storage and retrieval. As a
>
> programmer, you deal with the logical model, it is the tables you write
>
> SQL to manipulate. As a programmer, you don't care about the physical
>
> model unless you think it needs to be modified for performance reasons.
>
> The fact that present database products have a physical model which can
>
> be, and therefore often is, an exact representation of the logical model
>
> leads too many people to make unfortunate modifications to their logical
>
> model when they should be thinking only about the physical model and how
>
> it can map to the (unchanged) logical model.
>
>
>
> It seems to me that you may be talking about something else here.
>
Right!
Tracking "businesss transactions" a "logical model" might be sufficient. Documenting inspection and maintainance we need a "conceptual" model. Interpreting relations as logical statements (propositions) we have to deal with propositions like "valve of type x produced by y has a cast iron case" and "valve of type x produced by y has a forged case" and both statements are true and legal. Try normalization without prior knowledge of technical development and producer policy.

Try detail planning (inspection, tests...) when you only know that "50 valves of type x" are ordered.

>
>
> I don't think it has anything to do with the languages or libraries,
>
> but merely with the attempt to define easily usable and easily manageable
>
> data structures. Having a normalised relational model of your data means
>
> that every element of data is easily accessible both individually and
>
> in context, easily updated (subject to constraints), easily compared
>
> both with its peers and with suitable other elements, easily filtered
>
> and easily aggregated or summarised (and even easily ignored).
>
Based on personal experiences must I disagree. Arrays without "index out of bound protection" had to be very simple. Since data structures became part of the standard library´of modern programming languages I prefer a more sophisticated approach. Normalization is useful for simple or for data with medium complexity. Realistic systems like SAP/R3 yields a number of tables beyound comprehension (>100000).  

>
>
> If you have a type of complex structure for which you do not need to
>
> deal with its internal complexity until after you have identified and
>
> retrieved it (or when you are constructing it prior to storage), then
>
> you can treat it as a "simple domain" in relational terms. Incidentally,
>
> this makes it an element of a tuple, it will not be a table, or a row
>
> of a table (though the physical representation in the back-end may look
>
> like anything at all).
>
Your assumption is not valid. As in the valve examples have to deal with the internal structure when querying (special case handling).

>
> For efficiency reasons you might need key-wise storage (in effect a key
>
> index) as well as or instead of pure column-wise storage, but that is
>
> about designing the physical storage layer.
>
>
>
> > - Try export a Access database table to a Excel worksheet and reimport
>
> > the data and compare the tables.
>
>
>
> What data property does this not preserve? But it doesn't really matter,
>
> they are different tools for different purposes and it is no surprise
>
> that a double translation would lose something unless the mechanisms had
>
> been specifically designed not to.
>
What is the benefit of "logical model" that cannot be mapped lossless to a physical storage? Sorry, but relations are abstractions of "record oriented" storages. Primary key is the y-coordinate and column-names are the correspondent x coordinates. Column oriented storages need a alternative y-address.

>
> "Feature under construction" judging by the documentation. It is a new
>
> way to deal with sub-types (in the Entity-Relationship modelling sense)
>
> and might turn out to be a good idea (or not) but I am sure that people
>
> will find ways to misuse it because it says "inheritance" and they will
>
> assume that it is the same as object inheritance.
>
What's wrong with that assumption?

>
> A real-world thing is either identifiable in the real world, or it isn't.
>
True! But what about ordered real-world things ordered and not currently present? Planing activities on these things is bread and butter for us. After finishing our activities every real-world thing is identifiable in your sense. Our solution is to create a internal system created identity. This identity is used to make the entity unique and for referential integrity.

> In the latter case we either don't store anything about it, or we consider
>
> it as one of a counted collection of a type that is identifiable. Another
>
> possibility is that we assign it a system-created identifier and mark
>
> the real-world thing with the identifier (which may be impossible and/or
>
> undesirable).
>
Why? What is your solution to our planning example?
>

m.f.G.

Karl Scheurer Received on Mon Aug 26 2013 - 12:20:44 CEST