7 <pořadí>10</pořadí> |
7 <pořadí>10</pořadí> |
8 |
8 |
9 <text xmlns="http://www.w3.org/1999/xhtml"> |
9 <text xmlns="http://www.w3.org/1999/xhtml"> |
10 <p> |
10 <p> |
11 One of the great parts of the <m:unix/> |
11 One of the great parts of the <m:unix/> |
12 <m:podČarou> |
12 <m:podČarou><m:unix tvar="vysvětlivka"/></m:podČarou> |
13 <m:unix tvar="vysvětlivka"/> |
13 culture is the invention<m:podČarou>which is attributed to Doug McIlroy, see <a href="http://www.catb.org/~esr/writings/taoup/html/ch07s02.html#plumbing">The Art of Unix Programming: Pipes, Redirection, and Filters</a></m:podČarou> |
14 </m:podČarou> culture is the invention<m:podČarou>which is attributed to Doug McIlroy, see <a href="http://www.catb.org/~esr/writings/taoup/html/ch07s02.html#plumbing">The Art of Unix Programming: Pipes, Redirection, and Filters</a></m:podČarou> |
|
15 of <em>pipes</em> and the idea<m:podČarou>see <a href="http://www.catb.org/~esr/writings/taoup/html/ch01s06.html">The Art of Unix Programming: Basics of the Unix Philosophy</a></m:podČarou> |
14 of <em>pipes</em> and the idea<m:podČarou>see <a href="http://www.catb.org/~esr/writings/taoup/html/ch01s06.html">The Art of Unix Programming: Basics of the Unix Philosophy</a></m:podČarou> |
16 that <em>one program should do one thing and do it well</em>. |
15 that <em>one program should do one thing and do it well</em>. |
17 </p> |
16 </p> |
18 |
17 |
19 <p> |
18 <p> |
45 <p> |
44 <p> |
46 According to this principle we can build complex and powerful programs (pipelines) by composing several simple, single-purpose and reusable programs. |
45 According to this principle we can build complex and powerful programs (pipelines) by composing several simple, single-purpose and reusable programs. |
47 Such single-purpose programs (often called <em>filters</em>) are much easier to create, test and optimize and their authors don't have to bother about the complexity of the final pipeline. |
46 Such single-purpose programs (often called <em>filters</em>) are much easier to create, test and optimize and their authors don't have to bother about the complexity of the final pipeline. |
48 They even don't have to know, how their programs will be used in the future by others. |
47 They even don't have to know, how their programs will be used in the future by others. |
49 This is a great design principle that brings us advanced flexibility, reusability, efficiency and reliability. |
48 This is a great design principle that brings us advanced flexibility, reusability, efficiency and reliability. |
50 Being in any role (author of a filter, builder of a pipeline etc.), we can always focus on our task only and do it well. |
49 Being in any role (author of a filter, builder of a pipeline etc.), we can always focus on our task only and do it well.<m:podČarou>see <a href="http://wiki.apidesign.org/wiki/Cluelessness">cluelessness</a> by Jaroslav Tulach in his <em>Practical API Design. Confessions of a Java Framework Architect</em></m:podČarou> |
51 And we can collaborate with others even if we don't know about them and we don't know that we are collaborating. |
50 And we can collaborate with others even if we don't know about them and we don't know that we are collaborating. |
52 Now think about putting this together with the free software ideas... How very! |
51 Now think about putting this together with the free software ideas... How very! |
53 </p> |
52 </p> |
54 |
53 |
55 <!-- |
54 <!-- |
82 |
81 |
83 </m:diagram> |
82 </m:diagram> |
84 --> |
83 --> |
85 |
84 |
86 |
85 |
87 <p>Bytes, text, structured data? XML, YAML, JSON, ASN.1</p> |
86 <p> |
|
87 Now the question is: how the data passed through pipes should be formatted and structured. |
|
88 There is wide spectrum of options from simple unstructured text files (just arrays of lines) |
|
89 through various <abbr title="delimiter-separated values e.g. CSV separated by comas">DSV</abbr> |
|
90 to formats like XML (YAML, JSON, ASN.1, Diameter, S-expressions etc.). |
|
91 Simpler formats look temptingly but have many problems and limitations (see the Pitfalls section in the <m:a href="classic-example">Classic pipeline example</m:a>). |
|
92 On the other hand, the advanced formats are capable to represent arbitrary object tree structures or even arbitrary graphs. |
|
93 They offer unlimited possibilities – and this is their strength and weaknes at the same time. |
|
94 </p> |
88 |
95 |
89 <p>Rules:</p> |
96 <!-- |
|
97 <blockquote>Everything should be made as simple as possible, but not simpler.</blockquote> |
|
98 --> |
90 |
99 |
91 <ul> |
100 <p> |
92 <li>a stream contains zero or more relations</li> |
101 It is not about the shape of the brackets, apostrophes, quotes or text vs. binary. |
93 <li>a relation has a name</li> |
102 It is not a technical question – it is in the semantic layer and human brain. |
94 <li>a relation has one or more attributes</li> |
103 Generic formats and their <em>arbitrary object trees/graphs</em> are (for humans, not for computers) difficult to understand and work with |
95 <li>a relation contains zero or more records</li> |
104 – compared to simpler structures like arrays, maps or matrixes. |
96 </ul> |
105 </p> |
97 |
106 |
|
107 <p> |
|
108 This is the reason why we have chosen the relational model as our logical model. |
|
109 This model comes from 1969<m:podČarou>invented and described by Edgar F. Codd, |
|
110 see <em>Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks, Research Report, IBM</em> from 1969 |
|
111 and <em>A Relational Model of Data for Large Shared Data Banks</em> from 1970, |
|
112 see also <a href="https://en.wikipedia.org/wiki/Relational_model">Relational model</a> |
|
113 </m:podČarou> |
|
114 and through decades it has proven its qualities and viability. |
|
115 This logical model is powerful enough to describe almost any data and – at the same time – it is still simple and easy to be understood by humans. |
|
116 </p> |
|
117 |
|
118 <p> |
|
119 Thus the <m:name/> are streams containing zero or more relations. |
|
120 Each relation has a name, one or more attributes and zero or more records (tuples). |
|
121 Each attribute has a name and a data-type. |
|
122 Records contain attribute values. |
|
123 We can imagine this stream as a sequence of tables (but the table is only one of many possible visual representations of such relational data). |
|
124 </p> |
98 |
125 |
99 <h2>What <m:name/> are?</h2> |
126 <h2>What <m:name/> are?</h2> |
100 |
127 |
101 <p> |
128 <p> |
102 <m:name/> are an open <em>data format</em> designed for streaming structured data between two processes. |
129 <m:name/> are an open <em>data format</em> designed for streaming structured data between two processes. |