According to my current understanding of relational database theory, each row of a table must contain exactly the same number of columns.

So is there is conventional means for handling cases where one might be tempted to create rows of variable length?

For example: Suppose I want a table that matches mothers to each of their children. Theoretically, one could break the 'fixed number of columns' rule by creating a table having a unique, variable length record for each mother. Of course, then all of the neat database operations become very complex, inefficient, etc.

I can see some obvious ways to handle this while maintaining the 'fixed number of columns' rule. For example, one could define enough columns to hold the maximum number of children expected (thereby sacrificing space efficiency). Or one could choose to have multiple rows for any one mother (then 'mother' can no longer be a primary key). Or one could use Memo fields, and impose some kind of customized formatting in the memo fields that would be cracked by a customized parser. Or...

Don't get me wrong. I'm not lobbying for variable length records, I'm merely curious as to what are the widely accepted means for accomodating those situations where using them might seem a natural way to deal with variably sized tuples.

I guess the way I'd be tempted to solve this problem would be to create a mothers table with a unique record for each mother which specifies the number of children and the name of, say the oldest.
The latter would be used in a relation into a table of children where each child's record points to its next younger sibling (or to null).

Is this basic approach (with refinements for obvious problems) what is commonly used, or is there a more widely accepted approach?