DB and coding logic of a simple addressbook app.

[mr.white]

Hello,

 

I would like to make an adress book app. I got the skills to achieve this goal in PHP. However I have a problem.

 

I have no idea about how to let user add multiple phone numbers, addresses, emails etc just like in today's mobile phones. How can I do this? I mean, how shall I design the DB in order to achieve this? Arrays? Or another table to store these datas and get the record count when showing phone number boxes etc?

 

What would you suggest?

 

Thank you very much for your ideas, highly appriciated.

[dbo]

If you're wanting users to be able to store this information you'll want to store it in a database. Before worrying about design or figuring out flatfile vs mysql vs something else you should probably just sit down and map out what data you want to store. From there you can build the appropriate hierarchy.

[post_phobic]

Im not really sure what you are asking. Are you asking how one can store multiple pieces of contact information per person (ie, Bob has a home phone, work phone and several email addresses) or are you asking how one would make a system where it is easy to add contact information in general?

 

There should be enough information on Google for the latter and regarding the former I believe it is customary if not wise to store multiple numbers per person horizontally such that you may have an address table with a column for Address 1 and another column for Address 2 (although it violates first normal form).  But then again, it all depends on what you are really trying to do.

[mr.white]

now mr post_phobic thanks anyway for your amazingly helpful message however do tell me, why would I ask here such a question if the answer existed already on google? I needed this to solve an urgent matter so yes of course I checked google before asking here and some other places as well. But no, it does not exist. And no, you did not get a bit of what I am asking. What I asked is a very complicated matter indeed. Not about storing multiple data per person whatsoever. Anyway I solved the issue last week with some delicious algorithms and XML. But as I said, thanks for your fantastic helpful idea of telling me that what you don't understand might exist already on google. Really, epic idea.

 

Im not really sure what you are asking. Are you asking how one can store multiple pieces of contact information per person (ie, Bob has a home phone, work phone and several email addresses) or are you asking how one would make a system where it is easy to add contact information in general?

 

There should be enough information on Google for the latter and regarding the former I believe it is customary if not wise to store multiple numbers per person horizontally such that you may have an address table with a column for Address 1 and another column for Address 2 (although it violates first normal form).  But then again, it all depends on what you are really trying to do.

[post_phobic]

My mistake mr.white.  If you can accept my apology, how did you finally solve the problem? Just asking out of curiosity/to learn etc..

[mr.white]

By storing a Unique ID, Name and Surname or just the ID in their own fields and rest of the data in XML format in another one or in an easy to access file. When adding a contact a default XML file will be treated like a schema to display a default list of input elements when adding a contact. And when or if the user decides to expand this form to have, let's say, 5 emails, 3 more addresses or 2 different employer information, I will create input elements on the go by courtesy of JavaScript. When posted, a very simple PHP script reads the form, converts it to an XML file and stores is along with the Name and ID. System functions the same way when displaying the details of a contact or editing the information. Reading the XML file, printing the results or creating a form and input boxes with data placed in them on the go.

 

And why do this? Because this way, user can decide what he/she wants to store instead of just filling out a solid form which lets no easy modification, and do it without manipulating the structure of the DB. Because this way, when I give out this product, and when people want different default input elements for a contact, I (or they) will just need to modify an XML file. No form, no DB arrangements. Because this way can be applied to practically any web based application aimed to solve enterprise issues. Keeping track of goods, clients, finances. They all requiere forms and data to be stored which sometimes needed to be expanded. Oh and no need to mention when working with Google Gears, it will be a lot more easier to load the data just once, treat them as objects, and do all the stuff that would require server side treatment with JS thus it will function just like any other regular desktop app. And if I ever need to share the contact information between systems, sites etc, this code can be used universally and it will be very, very fast indeed instead of dumping and copying DBs.

 

And why you can't find this in Google, or at least I couldn't? Because developer do not care much about user experience or flexibility. Now isn't it cool to store whatever data you want just like in mobile phones, because even Outlook is pretty limited and it sux in a lot of ways. And isn't it cool to be able to use a clear XML to share the contact information instead of using horrible CSV file system?

 

Good day.

 

My mistake mr.white.  If you can accept my apology, how did you finally solve the problem? Just asking out of curiosity/to learn etc..