title: How is a SQL table different from an array of structs? (In terms of usage, not implementation)
body: <p>Here's a simple example of an SQL table:</p>
  
  <pre><code>CREATE TABLE persons
  (
      id INTEGER,
      name VARCHAR(255),
      height DOUBLE
  );  
  </code></pre>
  
  <p>Since I haven't used SQL very much, I haven't yet learned to think in its terms. Effectively, my brain translates the above into this:</p>
  
  <pre><code>struct Person
  {
      int id;
      string name;
      double height;
  
      Person(int id_, const char* name_, double height_)
      :id(id_),name(name_),height(height_)
      {}
  };
  Person persons[64];
  </code></pre>
  
  <p>Then, inserting some elements, in SQL:</p>
  
  <pre><code>INSERT INTO persons (id, name, height) VALUES (1234, 'Frank', 5.125);
  INSERT INTO persons (id, name, height) VALUES (5678, 'Jesse', 6.333);
  </code></pre>
  
  <p>...and how I'm thinking of it:   </p>
  
  <pre><code>persons[0] = Person(1234, "Frank", 5.125);
  persons[1] = Person(5678, "Jesse", 6.333);
  </code></pre>
  
  <p>I've read that SQL can be thought of as two major parts: data manipulation and data definition. I'm more concerned about organizing my data in the first place, as opposed to querying and modifying it. There, the distinctions of SQL are immediately obvious. To me, it seems like the subtleties of how data can and should be structured in SQL is a more obscure topic. Where does the array-of-structs analogy I'm automatically drawing for myself break down?</p>
  
  <p>To give a concrete example, let's say that I want each entry in my <code>persons</code> table (or each of my <code>Person</code> objects) to contain a field denoting the names of that person's children (actual fruit-of-your-loins children, not hierarchical data structure children). In reality, these would probably be cross-table references (or pointers to objects), but let's keep things simple and make this field contain zero or more names. In my C++ example, I'd modify the declaration like so:</p>
  
  <pre><code>vector&lt;string&gt; namesOfChildren;
  </code></pre>
  
  <p>...and do something like this:</p>
  
  <pre><code>persons[0].namesOfChildren.push_back("John");
  persons[0].namesOfChildren.push_back("Jane");
  </code></pre>
  
  <p>But, from what I can tell, the typical usage of SQL doesn't mirror this approach. If I'm wrong and there's a simple, straightforward solution, great. If not, I'm sure a SQL novice like myself could benefit greatly from a little cogitation on the subject of how databases of SQL tables are meant to be used in contrast to bare, generic data structures.</p>