OOoo ... a little discussion about schema design. Delicious:
So, if these lists are going to be composed of similar items, particularly wherein the user might benefit from seeing "popular" items or autocomplete functionality, you'll probably want a structure similar to this:
ListID | ListName
ItemID | ItemName | AverageItemCost | Desc | Popularity
ListItemID | ListID | ItemID | Qty | ItemCost
There's a little redundancy -- multiple lists may have the same item listed at the same quantity. Similarly, the ItemCost for any given list of item X may equal the AverageItemCost, but the user is then free to change that cost on their personal list without destroying the relationship to the base item.
So, why have the base item? Well, you certainly don't need it; it is primarily beneficial in implement aggregate functions more efficiently. It's more efficient to pull suggested items from the system if you can pull a SINGLE row that matches certain criteria, rather than pulling MANY rows matching certain criteria and then GROUP()ing, SUM()ing, or COUNT()ing. You need perform your aggregate functions only when a row is added (or modified). The assumption is that the general items list will be SELECTed from more often than it is written to.
Also, depending on the average ItemName and Desc lengths, you could save on space by using that 3rd table (Items). That along may be sufficient justification.
But, if space isn't a concern, which it probably isn't in this case, and you're NEVER going to have pan-user autocomplete, autosuggest, or "popular items" features, then you can probably stand to forgo the more normalized form without any noticeable consequence -- aside from the burning fire in your soul that comes from knowing a more normalized form that performs equally well is just within reach. But, if you're not using any fancy features that benefit from the normalization, and you can cope with that burning fire, use the 2-table form suggested by yamaharuss, as it will result in slightly less complex looking queries (but probably no difference in efficiency):
ListID | ListName
ListItemID | ListID | ItemName | ItemCost | Qty | Desc
ListItemId is actually a pretty important field according to some pretty experiences database folks, provided that it's an auto-incrementing INT (or BIGINT). MyISAM stores the PK anyway, so you may as well expose it. And InnoDB yields greater efficiency a majority of the time for having it on oft-written to tables, since it stores records in order of the PK. An auto-incrementing (big)INT PK instructs InnoDB to write rows in-order as they're INSERTed, avoiding the overhead of reorganizing the base row. From a programmatic perspective it's faster, simpler, and typical/normal/expected to reference rows by PK than by FK1 + FK2 + ... + FKN. And of course, from a purely philosophical perspective, every row effectively has an ID anyway -- so we may as well be explicit about it and provide a concrete, knowable ID (aside form the sum of the information present in the row).
In terms of the expectation that these rows will NEVER be duplicated -- I disagree. We don't have enough information to make that assumption. In the very least, we can probably consolidate ItemName and/or Desc into their own table(s) to approach a more flexible and normalized design. Fields such as Qty and ItemCost may be good bonus fields (aggregate function caches) to cut back on repeating more expensive queries. But in short, the only significant benefit I see in this case for avoiding the more normalized form is to make the queries slightly more readable.
This is contingent, again, on the assumption that ItemName will at least be duplicated to some extent. And since the same ItemName might show up on multiple lists, it's also possible to save on space by also providing a suggested description when a user types in "boots" or something ... We're then left only with the unanswerable philosophical question of whether items with the same name are all the same or items with the same name and description ... The unanswerable question is often best "answered" by introducing 2 more tables, actually:
DescriptionId | DescriptionText | Popularity
ItemDescriptionId | ItemId | DescriptionId | Popularity
By doing this, we potentially save on space and allow ourselves more sophisticated auto-complete, auto-suggest, and "popular items" functionality to the users without sacrificing much at all on efficiency.