seperator instead of a comma for listed items in DB?

I'm making a recipe database, and need to have DB fields in mySQL that
will have lists of values that would get sent to an array to be worked
on.

I anticipate that at times a comma will need to be used in the value
itself. So, what's a commonly used symbol or something that people tend
to use as a separator of a list that would then be used in the split()
function to send the elements into an array?

Nearly every punctuation has a chance of being in the actual data. Any
suggestions?

Thanks!
Liam

news@celticbear.com wrote:
> I'm making a recipe database, and need to have DB fields in mySQL that
> will have lists of values that would get sent to an array to be worked
> on.
>
> I anticipate that at times a comma will need to be used in the value
> itself. So, what's a commonly used symbol or something that people tend
> to use as a separator of a list that would then be used in the split()
> function to send the elements into an array?
>
> Nearly every punctuation has a chance of being in the actual data. Any
> suggestions?
>
> Thanks!
> Liam
>
Usually the vertical bar '|' is a good choice.

-david-

news@celticbear.com wrote:
> I'm making a recipe database, and need to have DB fields in mySQL that
> will have lists of values that would get sent to an array to be worked
> on.
>
> I anticipate that at times a comma will need to be used in the value
> itself. So, what's a commonly used symbol or something that people tend
> to use as a separator of a list that would then be used in the split()
> function to send the elements into an array?
>
> Nearly every punctuation has a chance of being in the actual data. Any
> suggestions?
>
> Thanks!
> Liam

I usually use an ASCII control character. 0x1E is designated as a
record seperator. Don't know if MySQL would accept it or not.

Chung Leong wrote:
> news@celticbear.com wrote:
> > I'm making a recipe database, and need to have DB fields in mySQL that
> > will have lists of values that would get sent to an array to be worked
> > on.
> >
> > I anticipate that at times a comma will need to be used in the value
> > itself. So, what's a commonly used symbol or something that people tend
> > to use as a separator of a list that would then be used in the split()
> > function to send the elements into an array?
> >
> > Nearly every punctuation has a chance of being in the actual data. Any
> > suggestions?
> >
> > Thanks!
> > Liam
>
> I usually use an ASCII control character. 0x1E is designated as a
> record seperator. Don't know if MySQL would accept it or not.

Interesting.
I had to do a search on control characters and that 0x1e, because I
have no idea what they are.
(Well, except in Windows I know I can use ALT+(numpad) to write ASCII
characters, but that's beside the point.

Evidently 0x1e is shown as two carrets: ^^
When I create the full value that would go into the field, would I
simply insert ^^ between the different values before it gets sent to
mySQL, and then use ^^ as the split() seperator?
Or do I have to use that 0x1e label in some way?

Does the ^^ tell mySQL or PHP something special?
I can't seem to find anything with Google on it.

Thanks for the reply!
-Liam

news@celticbear.com wrote:
> need to have DB fields in mySQL that
> will have lists of values

Typically, one would use escape characters. For example, | would be
used to seperate two fields. A literal | would be escaped: \|. This
makes it possible to use the seperation character in the data.

Another, probably better option, would be to make a seperate table.
Instead of storing the ingredients seperated by a character like this:
1, Chinese Chicken, chicken|salt|pepper|mushrooms
Think about making a ingredients table and storing it there:

[Recipes]
1, Chinese Chicken
2, Meatloaf

[Ingredients]
1, chicken
1, salt
1, pepper
1, mushrooms
2, meat
2, loaf

This makes it easy to search and it is more logical from a DB point of
view.

news@celticbear.com wrote:
> Chung Leong wrote:
> > news@celticbear.com wrote:
> > > I'm making a recipe database, and need to have DB fields in mySQL that
> > > will have lists of values that would get sent to an array to be worked
> > > on.
> > >
> > > I anticipate that at times a comma will need to be used in the value
> > > itself. So, what's a commonly used symbol or something that people tend
> > > to use as a separator of a list that would then be used in the split()
> > > function to send the elements into an array?
> > >
> > > Nearly every punctuation has a chance of being in the actual data. Any
> > > suggestions?
> > >
> > > Thanks!
> > > Liam
> >
> > I usually use an ASCII control character. 0x1E is designated as a
> > record seperator. Don't know if MySQL would accept it or not.
>
> Interesting.
> I had to do a search on control characters and that 0x1e, because I
> have no idea what they are.
> (Well, except in Windows I know I can use ALT+(numpad) to write ASCII
> characters, but that's beside the point.
>
> Evidently 0x1e is shown as two carrets: ^^
> When I create the full value that would go into the field, would I
> simply insert ^^ between the different values before it gets sent to
> mySQL, and then use ^^ as the split() seperator?
> Or do I have to use that 0x1e label in some way?
>
> Does the ^^ tell mySQL or PHP something special?
> I can't seem to find anything with Google on it.

Do something like implode("\x1B", $record);. The character is
definitely not two carets.

Sjoerd wrote:
> news@celticbear.com wrote:
> > need to have DB fields in mySQL that
> > will have lists of values
>
> Typically, one would use escape characters. For example, | would be
> used to seperate two fields. A literal | would be escaped: \|. This
> makes it possible to use the seperation character in the data.
>
> Another, probably better option, would be to make a seperate table.
> Instead of storing the ingredients seperated by a character like this:
> 1, Chinese Chicken, chicken|salt|pepper|mushrooms
> Think about making a ingredients table and storing it there:
>
> [Recipes]
> 1, Chinese Chicken
> 2, Meatloaf
>
> [Ingredients]
> 1, chicken
> 1, salt
> 1, pepper
> 1, mushrooms
> 2, meat
> 2, loaf
>
> This makes it easy to search and it is more logical from a DB point of
> view.

Well, since you brought it up, speaking of the DB, that's kind of what
I had in mind, but, differemt.
The tbl_ingredients would have two columns, ID and NAME like:
1, garlic
2, chicken
3, pepper
4, salt
etc...

Then the tbl_recipes would have colums like:
ID, NAME, INGREDIENTS, MEASUREMENTS, NOTES
with data like:
1, Chinese Chicken, 1|2|3|4, 1 clove|1 lbs. breast| 1 tsp.| 1 T., more
stuff here....

Where the ingredients would be the ingredient's ID in a CSV, (but
obviously using something other than a comma,).
That's the best I could come up with to be able to have a list of
unknown and constantly changing number of ingredients that would save
space in the table.

The problem I'm seeing with your suggestion is that the [ingredients]
table would have a lot of redundant info.
Every recipe that required pepper would have a row with a recipie ID
and a value of "garlic," which would be repeated in the database n
number of times.

I suppose of course, if the database remains small, that amount of
redundant data isn't going to hurt performance at all.... and would
possibly be easier to manage....

Thanks for the reply and the feedback!!
-Liam

news@celticbear.com wrote:
> Sjoerd wrote:
>> news@celticbear.com wrote:
>>> need to have DB fields in mySQL that
>>> will have lists of values
>> Typically, one would use escape characters. For example, | would be
>> used to seperate two fields. A literal | would be escaped: \|. This
>> makes it possible to use the seperation character in the data.
>>
>> Another, probably better option, would be to make a seperate table.
>> Instead of storing the ingredients seperated by a character like this:
>> 1, Chinese Chicken, chicken|salt|pepper|mushrooms
>> Think about making a ingredients table and storing it there:
>>
>> [Recipes]
>> 1, Chinese Chicken
>> 2, Meatloaf
>>
>> [Ingredients]
>> 1, chicken
>> 1, salt
>> 1, pepper
>> 1, mushrooms
>> 2, meat
>> 2, loaf
>>
>> This makes it easy to search and it is more logical from a DB point of
>> view.
>
> Well, since you brought it up, speaking of the DB, that's kind of what
> I had in mind, but, differemt.
> The tbl_ingredients would have two columns, ID and NAME like:
> 1, garlic
> 2, chicken
> 3, pepper
> 4, salt
> etc...
>
> Then the tbl_recipes would have colums like:
> ID, NAME, INGREDIENTS, MEASUREMENTS, NOTES
> with data like:
> 1, Chinese Chicken, 1|2|3|4, 1 clove|1 lbs. breast| 1 tsp.| 1 T., more
> stuff here....
>
> Where the ingredients would be the ingredient's ID in a CSV, (but
> obviously using something other than a comma,).
> That's the best I could come up with to be able to have a list of
> unknown and constantly changing number of ingredients that would save
> space in the table.
>
> The problem I'm seeing with your suggestion is that the [ingredients]
> table would have a lot of redundant info.
> Every recipe that required pepper would have a row with a recipie ID
> and a value of "garlic," which would be repeated in the database n
> number of times.
>
> I suppose of course, if the database remains small, that amount of
> redundant data isn't going to hurt performance at all.... and would
> possibly be easier to manage....
>
> Thanks for the reply and the feedback!!
> -Liam
>

How about this instead?

Three tables: Recipe, Quantity, Ingredient

Recipe
ID, NAME, DESCRIPTION, AUTHOR, ...

Ingredient
ID, DESCRIPTION

Quantity
RECIPE_ID, INGREDIENT_ID, AMOUNT, UNIT

That way you could have:

Recipe:
1, 'Chinese Chicken', 'A neat recipe that is easy to make', ...

Ingredient:
1, 'Garlic'
2, 'Chicken'
3, 'Salt'
4, 'Pepper'

Quantity:
1, 1, 1, 'clove'
1, 2, 1, 'lb white meat'
1, 3, 1, 'tsp'
1, 4, 1, 'tbsp'

Then, let's say you have another recipe that calls for salt.

Recipe:
2, 'Mashed Potatoes', 'Light and fluffy mashed potatoes'

Ingredient:
5, 'Potatoes'
6, 'Buttermilk'

Quantity:
2, 3, 1, 'tbsp'
2, 5, 2, 'lbs cubed'
2, 6, .25, 'cup'
2, 4, 0, 'to taste'

etc.

-david-

David Haynes wrote:
> news@celticbear.com wrote:
> > Sjoerd wrote:
> >> news@celticbear.com wrote:
> >>> need to have DB fields in mySQL that
> >>> will have lists of values
> >> Typically, one would use escape characters. For example, | would be
> >> used to seperate two fields. A literal | would be escaped: \|. This
> >> makes it possible to use the seperation character in the data.
> >>
> >> Another, probably better option, would be to make a seperate table.
> >> Instead of storing the ingredients seperated by a character like this:
> >> 1, Chinese Chicken, chicken|salt|pepper|mushrooms
> >> Think about making a ingredients table and storing it there:
> >>
> >> [Recipes]
> >> 1, Chinese Chicken
> >> 2, Meatloaf
> >>
> >> [Ingredients]
> >> 1, chicken
> >> 1, salt
> >> 1, pepper
> >> 1, mushrooms
> >> 2, meat
> >> 2, loaf
> >>
> >> This makes it easy to search and it is more logical from a DB point of
> >> view.
> >
> > Well, since you brought it up, speaking of the DB, that's kind of what
> > I had in mind, but, differemt.
> > The tbl_ingredients would have two columns, ID and NAME like:
> > 1, garlic
> > 2, chicken
> > 3, pepper
> > 4, salt
> > etc...
> >
> > Then the tbl_recipes would have colums like:
> > ID, NAME, INGREDIENTS, MEASUREMENTS, NOTES
> > with data like:
> > 1, Chinese Chicken, 1|2|3|4, 1 clove|1 lbs. breast| 1 tsp.| 1 T., more
> > stuff here....
> >
> > Where the ingredients would be the ingredient's ID in a CSV, (but
> > obviously using something other than a comma,).
> > That's the best I could come up with to be able to have a list of
> > unknown and constantly changing number of ingredients that would save
> > space in the table.
> >
> > The problem I'm seeing with your suggestion is that the [ingredients]
> > table would have a lot of redundant info.
> > Every recipe that required pepper would have a row with a recipie ID
> > and a value of "garlic," which would be repeated in the database n
> > number of times.
> >
> > I suppose of course, if the database remains small, that amount of
> > redundant data isn't going to hurt performance at all.... and would
> > possibly be easier to manage....
> >
> > Thanks for the reply and the feedback!!
> > -Liam
> >
>
> How about this instead?
>
> Three tables: Recipe, Quantity, Ingredient
>
> Recipe
> ID, NAME, DESCRIPTION, AUTHOR, ...
>
> Ingredient
> ID, DESCRIPTION
>
> Quantity
> RECIPE_ID, INGREDIENT_ID, AMOUNT, UNIT
>
> That way you could have:
>
> [..]
> -david-

Huh, OK. I hadn't thought of it that way. Intuitively it wouldn't seem
like you'd want to have the unique data that makes up the components of
the recipe in a "quantity" table as opposed to the table that contains
the recipe name and details, etc.
That erroneous thinking is what led me to the silliness of trying to
shove multiple data values into one field.
This solves (makes irrelevant) my array/CSV problem.
Thanks for the clue-by-four!
-Liam

news@celticbear.com wrote:
> David Haynes wrote:
>> news@celticbear.com wrote:
>>> Sjoerd wrote:
>>>> news@celticbear.com wrote:
>>>>> need to have DB fields in mySQL that
>>>>> will have lists of values
>>>> Typically, one would use escape characters. For example, | would be
>>>> used to seperate two fields. A literal | would be escaped: \|. This
>>>> makes it possible to use the seperation character in the data.
>>>>
>>>> Another, probably better option, would be to make a seperate table.
>>>> Instead of storing the ingredients seperated by a character like this:
>>>> 1, Chinese Chicken, chicken|salt|pepper|mushrooms
>>>> Think about making a ingredients table and storing it there:
>>>>
>>>> [Recipes]
>>>> 1, Chinese Chicken
>>>> 2, Meatloaf
>>>>
>>>> [Ingredients]
>>>> 1, chicken
>>>> 1, salt
>>>> 1, pepper
>>>> 1, mushrooms
>>>> 2, meat
>>>> 2, loaf
>>>>
>>>> This makes it easy to search and it is more logical from a DB point of
>>>> view.
>>> Well, since you brought it up, speaking of the DB, that's kind of what
>>> I had in mind, but, differemt.
>>> The tbl_ingredients would have two columns, ID and NAME like:
>>> 1, garlic
>>> 2, chicken
>>> 3, pepper
>>> 4, salt
>>> etc...
>>>
>>> Then the tbl_recipes would have colums like:
>>> ID, NAME, INGREDIENTS, MEASUREMENTS, NOTES
>>> with data like:
>>> 1, Chinese Chicken, 1|2|3|4, 1 clove|1 lbs. breast| 1 tsp.| 1 T., more
>>> stuff here....
>>>
>>> Where the ingredients would be the ingredient's ID in a CSV, (but
>>> obviously using something other than a comma,).
>>> That's the best I could come up with to be able to have a list of
>>> unknown and constantly changing number of ingredients that would save
>>> space in the table.
>>>
>>> The problem I'm seeing with your suggestion is that the [ingredients]
>>> table would have a lot of redundant info.
>>> Every recipe that required pepper would have a row with a recipie ID
>>> and a value of "garlic," which would be repeated in the database n
>>> number of times.
>>>
>>> I suppose of course, if the database remains small, that amount of
>>> redundant data isn't going to hurt performance at all.... and would
>>> possibly be easier to manage....
>>>
>>> Thanks for the reply and the feedback!!
>>> -Liam
>>>
>> How about this instead?
>>
>> Three tables: Recipe, Quantity, Ingredient
>>
>> Recipe
>> ID, NAME, DESCRIPTION, AUTHOR, ...
>>
>> Ingredient
>> ID, DESCRIPTION
>>
>> Quantity
>> RECIPE_ID, INGREDIENT_ID, AMOUNT, UNIT
>>
>> That way you could have:
>>
>> [..]
>> -david-
>
> Huh, OK. I hadn't thought of it that way. Intuitively it wouldn't seem
> like you'd want to have the unique data that makes up the components of
> the recipe in a "quantity" table as opposed to the table that contains
> the recipe name and details, etc.
> That erroneous thinking is what led me to the silliness of trying to
> shove multiple data values into one field.
> This solves (makes irrelevant) my array/CSV problem.
> Thanks for the clue-by-four!
> -Liam
>
Glad to help.

The 'Quantity' table is better known as a 'many-to-many' join table and
is used quite a lot in database schema design. It is called
'many-to-many' since a recipe may use many ingredients and an ingredient
may be used in many recipes.

-david-