title: Relational DB schema design - How to model 1-to-1 mapping right from an entity's set of fields
body: <p>I am working on a <code>MySQL</code> (via Prisma datamodel) schema for a <code>Customer</code> entity in an e-commerce context. As the number of fields have exploded (on including say, engagement tracking) I have two possible designs here:</p>
  <pre><code>type Customer {
    email: String! @unique
    name: String
    birthDate: DateTime
    addresses: [Address!]!
    ...
    productsVisited: [Product!]!
    productsShared: [Product!]!
    productsSearched: [Product!]!
    ...
  }
  </code></pre>
  <p><strong>That, or should fields conveying info together should be carved out into their own table, and joined to the previous one by a 1-to-1 relation:</strong></p>
  <pre><code> type Customer {
    profile: CustomerProfile! @relation(name: &quot;CustomerProfile&quot;, onDelete: CASCADE)
    addresses: [Address!]!
    ...
    productEngagements: ProductEngagement! @relation(name: &quot;CustomerProductEngagements&quot;, onDelete: CASCADE)
    ...
  }
  
  type CustomerProfile {
    customer: Customer! @relation(name: &quot;CustomerProfile&quot;, onDelete: SET_NULL)
    email: String! @unique
    name: String
    birthDate: DateTime
  }
  
  type ProductEngagement {
    customer: Customer! @relation(name: &quot;CustomerProductEngagements&quot;, onDelete: SET_NULL)
    productsVisited: [Product!]!
    productsShared: [Product!]!
    productsSearched: [Product!]!
  }
  </code></pre>
  <p><strong>QUESTIONS:</strong></p>
  <blockquote>
  <ol>
  <li><p>What is the right way of thinking design here? I am currently driven by my ER diagrams, and intuition. Do I get or lose any execution or flexibility advantage with making a table thin w.r.t. number of columns?</p>
  </li>
  <li><p>In the second method, do queries have to do extra work for table joins?</p>
  </li>
  </ol>
  </blockquote>
  <p><strong>Abstract Question:</strong></p>
  <blockquote>
  <p>Is a method definitely better than the other, given evolving schema, or performance criteria? Or, is this just a matter of taste here?</p>
  </blockquote>