Would you use CI for this?

[eluser]Puzzled1[/eluser]
Hello everyone!

I am unsure what software to use for a project I'm about to start.
It's supposed to be a database-driven contact management tool, managing about 16.000 to 20.000 addresses.

The requirements are what pose some problems for me:
* Apart from the fields you would expect (name, firstname, mail, city, street, etc), there also will have to be a few fields that group the contacts by group membership or certain other attributes - let's call them tags for now.
* The number of those tags and groups is unknown to me and will increase over time
* This also means that those tags and groups have to be kinda dynamic. New tags will come up. One MySql-SET field will probably not be enough.
* There won't be any need for user-to-user-relationships.
* 16.000 addresses seems like a lot.
* Search results should be exported in an Excel-Sheet (shouldn't be a problem)
* New addresses should be added by uploading an Excel-Sheet.
* Said uploads should not lead to double entries in the databank.

So... would you guys use CodeIgniter for this project? Did someone program anything like this before?

Right now I'm not even sure what to use as a primary key and how to make sure that 2 persons with the same name are or aren't one and the same. This problem is amplified by the fact that I won't have all the information all the time. Sometimes name and e-mail address will be everything I have, other times name, address and phone number will be there but no mail.

Sorry if I'm in the wrong forum.

Thanks for any hints, thoughts and criticisms.

[eluser]frenzal[/eluser]
I don't see why you wouldn't use CI for such a project, you can use it for everything. However there might be other contact management systems that already exist you could use/purchase instead, but that's something you'll need to research.

And if you're system isn't 100% sure a contact is a duplicate or coincendantly has the same name, just let the user choose.

[eluser]nmweb[/eluser]
16.000 is nothing for a database. Tags and groups should be handled by relationships with other tables. I only see a problem with importing Excel-sheets which might be tricky but I'm sure there are libraries out there to help you.

Primary key should be an id field, that's easiest. Making sure 2 persons are not the same might be handled by nifty Mysql functions (see mysql manual) or resort to php which is less neat.

[eluser]webthink[/eluser]
I wouldn't think of using anything else. Seems like a fairly standard web app to me. Easily done in codeIgniter. Don't let the number of rows worry you as that doesn't dictate the size of an application. From what you've said it's only about two tables. The excel thing can be really easy if all you need tabulated data. You could export standard html tables or csv's. If you need real excel formatting that can be done as well. Do a search on the forum.

[eluser]Puzzled1[/eluser]
Thanks for all the replies (so quick!).

Good. CodeIgniter it is.

I've done exporting excel files with CI before (looooong time ago though) There's a how-to along with a little class on this forum if I remember correctly. Importing will be tough (for me at least), but I'm sure there are some classes out there somewhere.

I guess, letting the user decide whether or not something is a duplicate entry will work.

There's still a few things I can't wrap my head around:
* How will I deal with the tags. As I mentioned, the number of tags will increase. Also, I have to make sure there won't be any tags like "music fan" and "music fanatic" at the same time. I was thinking I would present a <select> field to the user to make sure of that. But how can I make the table expandable once the 64 tags in a SET field are used up?
* How exactly is the application supposed to decide whether to update or set data? Again, the tags are what might cause headaches. I'm imagining cases where everything is equal except for the tags. I can't let the users iterate through every line when an excel sheet with 200 entries or more is being uploaded.

Well, I guess all of this will become much more clear once I start coding which I will do right now.
Thanks again for your comments!

[eluser]webthink[/eluser]
store the tags in a seperate table. Use that table to populate the dropdown... if there is only one tag per contact then the contact table will have a tag_id field that corresponds to a record in the tags table.
If you want to make it possible to add tags on the fly provide an additional text field and if that has any input ignore the select input and use that to add a new row to the tags table. Return last insert id to use as a foreign key in the contacts table.

[eluser]Puzzled1[/eluser]
[quote author="webthink" date="1205429725"]store the tags in a seperate table. Use that table to populate the dropdown... if there is only one tag per contact then the contact table will have a tag_id field that corresponds to a record in the tags table.
If you want to make it possible to add tags on the fly provide an additional text field and if that has any input ignore the select input and use that to add a new row to the tags table. Return last insert id to use as a foreign key in the contacts table.[/quote]
The number of tags can range from zero to 20 (educated guess, more is possible but unlikely). If I understand you correctly, this approach won't work quite as easily.

[eluser]webthink[/eluser]
Ah ok... Then what you want is a relationship table (tags_contacts) in addition to your tags and contacts tables. This table would just have fields tag_id, and contact_id

[eluser]adamp1[/eluser]
I was thinking a better way for the tag input would be just a text box. Then as you type it auto completes AND returns like tags already created.

That way if someone types 'fanatic' and their is a 'music fanatic' tag & a 'game fanatic' tag both will show. That way its sill in the ball park of the user not to create duplicates. You could also have a thing so new tags have to be approved, but depending on how many new tags are created each time this could get overwhelming.

Sounds quite a nice application. I prefer building data applications on the web rather than websites. I don't know but they seem more fun and more challenging. Also it has the add advantages since it most likely will be used in house that it won't have to work on every version of IE, and can use lots of nice ajax without worry.

(That is if you have a say on what its run on, which half the time I do)

[eluser]Puzzled1[/eluser]
:-) Not worrying about IE is great, indeed. And this is quite a challenge to me - I'm not a "real" programmer at all.

I've never done any Ajax and I personally dislike javascript, so I'll try not to get involved with it unless absolutely necessary.

This app will be used by about 15 people including me and another php-savvy colleague. The rest of the bunch are total computer illiterates. But they can use Excel and some simple data entering in a form will be ok. :-)

I'm not sure I totally grasp the relationship table.. would that look something like this:

table contact
id | name | ... | tags
1 | Bob | ... | 1,2
2 | Sam | ... | 2,3

table tags
id | tag
1 | skiing
2 | music

relationship table v.1
tag_id | contact_id
1 | 1
2 | 1,2
3 | 2


or:
relationship table v.2
tag_id | contact_id
1 | 1
2 | 1
2 | 2
3 | 2