Adding Rows Against Adding Columns

## Two operations, not one setting A **labelled table** here means a rectangle of named columns that, in some tools, also carries an identifier for each row. There are two entirely different ways to combine one with another, and confusing them is the most common thing an interviewer is testing at this level. **Stacking pieces** means putting two pieces that mean the same thing one under the other, so the result is longer. You are **adding records**. Twelve monthly pieces of one report are twelve batches of the same kind of fact, and what makes them stackable is that they share a column vocabulary. **Gluing side by side** means putting two tables next to each other so that each output row is one row of each, and the result is wider. You are **adding attributes**. A block of computed scores placed beside the customers they were computed for adds columns, not rows. Many tools expose both through a single call with a setting that says whether records or attributes are being added, and that packaging is exactly why people think of them as one operation with a knob on it. They are not. They have different preconditions, different expected output counts, and different silent failures. ## What each one assumes 1. **A stack assumes a shared column vocabulary.** It does not assume anything about the rows: two pieces of different lengths stack happily, and that is the point. What it needs is that a column meaning the same thing is called the same thing on both pieces. 2. **A glue assumes a row correspondence.** It does not assume anything about the columns: they can be completely different, and that is the point. What it needs is that row three of one side really is the same record as row three of the other, or that whatever the tool pairs on is the record's identity. 3. **Neither operation compares records.** Nothing in either call looks at a customer number and checks it against a customer number. That is a third operation - matching two tables on a key - and it is the thing you actually want whenever you are unsure. ## The arithmetic to state before you run it Say the expected numbers out loud first; a candidate who does this catches almost everything in this category. | | Stacking pieces (adding records) | Gluing side by side (adding attributes) | |---|---|---| | Result is | longer | wider | | What must agree | the column set | the row correspondence | | Expected row count | the sum of the pieces' row counts | the shared row count, where the pairing is positional | | Expected column count | the shared set, or the union of the two sets | the sum of the two column counts | | Silent failure | a column named differently on one piece becomes two partly filled columns | values land beside the wrong records | | Cheapest check | compare the two pieces' column names as sets | spot-check an identifying value on both sides of a few rows | ## Where the designs genuinely differ This is a family of tools across several ecosystems, and they do not agree here, so answer for the class rather than for the one you use: - **A stack whose pieces disagree on columns** may take the union of the two column sets and fill the gaps with the tool's representation of a value that is not there, may refuse the call until the sets match, or may reconcile the pieces by position rather than by name. - **A side-by-side glue** may be a positional pairing that only checks that the two lengths agree, or, in tools that carry an identifier for each row, may line the two row-label sets up first and insert holes wherever a label appears on only one side - which means the result can have more rows than either input did. - **What a stack does to row identity** varies too: where rows have positions only, the result is simply longer; where each row carries a label, both pieces bring their labels along and the same label can now appear twice. So "it will just work" is not an answer for either operation. "Here is what mine does, and here is what I checked" is. ## What to do instead, when you can If both sides carry a column that identifies the record - an order number, a customer number, a date plus a store - then matching the two tables on that column is strictly better than gluing them side by side, because the pairing is stated in the code rather than inherited from whatever the previous step happened to leave behind. Gluing side by side is for the case where you genuinely built the second block from the first, in one pass, and nothing has re-ordered or filtered either since. For a stack, the equivalent discipline is cheap: compare the two pieces' column names as sets before combining, and compare the combined row count against the sum you predicted. Both take one line and both catch the failure at the seam instead of three steps downstream, where it looks like a data problem rather than a combining problem.