crtreedude

Hi all, newbie to PHP and a lot of HTML, not a newbie to programming (C++, SQL, and about 20+ other languages) Anyway, probably a simple problem. I have fields in a database that are in Spanish, so I end up with accents. For example, home phone is TeléfonoCasa I am calling a page using the field name like index.php?TableSort=TeléfonoCasa and as you probably guessed it, it mangles the accent character - and ideas oh gurus? Thanks ahead of time.

Let's step back a bit, 100,000 records is hardly anything. I have worked on a trillion record database. If it is working slow, it is due to not enough memory or no index on what you are searching. You should fix that first. You should be in 40 million records and above before you have to get good at tuning. Indexing is a way that you create a smaller table when you think of it.

One thing to realize is often you might be asking the wrong question. For example, you assume that you should be using an array when perhaps it is the wrong thing. As the old saying goes, when all you have is a hammer, everything looks like a nail. It is very important not to just try to do the same ole things with a new technology (new to you) but to spend some time understanding how it works. It will save much headache later.

If it is merely logs, and you don't have to work with individual rows, it actually makes sense to have no primary key. Uniqueness must be checked during insert with a primary key, but with a simple index, no. If one needs to update or delete individual records, you need a primary key, or uniqueness, otherwise, not really. For example, you can delete all records for a range of dates.

Is it a problem with mysql or just sql in general. It would seem to me that you are used to ISAM type databases or flat files and are trying to absorb how SQL itself works. If so, try a tutorial on SQL, it should help. Especially design. Manuals usually just tell you how to use the features, not why you want to.

Since a table/row/column definition is a form of an array - just persistent, there is no reason to store an array. Perhaps the best idea is to look at Entity Relationship Diagrams , do a little search on them and I am sure you will see how to lay this out. I am thinking the best would be to have 2 or 3 separate tables joined on keys. USER, I would use something like USER_ID as the primary. GAME - to discribe each game, might only be GAME_ID and DESCRIPTION USER_GAME, intersect between USER & GAME USER_ID GAME_ID .... other fields I hope this gives you an idea

Only if you wish to experience what your user name suggest, despair. Clean code will help you preserve what little sanity remains. Trust me on this. When a project gets really large, with lots of hands in it, locking everything down tight is the only way to not lose your mind. I remember restoring a SQL database once and the field orders actually changed. I would suggest that you shouldn't ever assume the order of fields. There is no guarantee.

If each of your sets represents a row, you don´t. And you aren't inserting, you are updating. Why do you wish to do it as a single statement? If you are concerned about data integrity while updating each row, wrap it with a transaction statement, which will make it atomic. (i.e. done as a unit, not as separate transactions) I would assume that your ID is the primary key for each row. Hope this helps.