Field types and disallowed characters

OK - probably a dumb question

I am working on setting up a DB with my ID field set as Primary Key

Currently I have the ID field type as varchar but the ‘order nos’ that I am using in this field I would like to take the format 12345-1, 12345-2 when there are 2 orders relating to 1 address. (Only half a dozen of the total 100 or so will require this)

But when I try and change the DB entry for 12345-1 from PHP on a FW webpage I get a MySQL error 1062 ‘Duplicate entry ‘12345-1’ for key 1’ error message

I am assuming that the ‘-’ character is being ignored and that is why I get the error.

What is the most suitable field type to use and if I change it on the existing DB will it affect the entries there already?

David


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Not sure how to help on this as I don’t know your table structure or
exactly what you are trying to do, but I generally find the way I
would set up a table that has an id as Primary Key would be to set it
to an ‘int’ and then select ‘auto increment’

This will automatically set the id as an entry is made, first entry
would be 1, second 2 etc. so you then have each entry with a unique id
that you can use to access data from that entry in that table (if you
need this?).

Then enter any other information you want in the table in columns
relative to the schema for your db.

For example:

id | address | other | other

1 | 12345 | ? | ?

2 | 12345 | ? | ?

3 | 17344 | ? | ?

This way ‘example above’ you have two entries for address/client 12345
so you can then pull the entries for that client.

The reason you get an error for duplicate entries is because you are
trying to make a duplicate entry, use something like PHPMyAdmin to
view the data from the database, it is an easy way of reading the
database structure and the data it contains and you can easily search/
test for data in any of the columns to match or whatever that you need
without writing out a script to do it.

If your id column has entries with a hyphen such as ‘12345-1’ then
that data would not be compatible with an ‘int’ field type. Personally
I would not use any hyphens in data unless it is in a piece of text, I
don’t really see the point, or at least not with anything I have ever
had the need to write. I tend to think of data in columns as
straightforward blocks of information, a digit, a number, a word, a
group of words/text or a path for example. Generally I would look at
something like ‘12345-1’ as two different items of data, which does
not mean is a bad way of stroing information. I often use several
peices of data in a column entry that is delimited and then explode
them into variables when the data is retreaived but this would be data
that I would never need to search for. Take your ‘12345-1’ as an
example: (I am not totally sure this is what you are doing but) two
entries with addresses/clients as ‘12345’ and two references to
entries ‘-1’ and ‘-2’, using two columns, one for the client or
address ‘12345’ and another for the id ‘1’ allows you to perform an
easy search for this data, having the id set to auto_increment then
knocks the id over 1 for each entry you make, so on entering the data
for the other columns ‘and not any id’ the id will automatically
increment by 1 for each entry.

If you need show the information somewhere as ‘12345-1’ as a reference
number then print out the number with a hyphen between the two
variables, again this is something I have done in the past and found
an easy way of doing that is to store the ‘-’ in a variable in a
config file and then when used the hyphen will show, if it needs to be
changed to ‘:’ then you just change the value of the variable in the
config file and it changes everywhere it is used.

HTH

On Feb 7, 2011, at 4:17 PM, DeltaDave wrote:

OK - probably a dumb question

I am working on setting up a DB with my ID field set as Primary Key

Currently I have the ID field type as varchar but the ‘order nos’
that I am using in this field I would like to take the format
12345-1, 12345-2 when there are 2 orders relating to 1 address.
(Only half a dozen of the total 100 or so will require this)

But when I try and change the DB entry for 12345-1 from PHP on a FW
webpage I get a MySQL error 1062 ‘Duplicate entry ‘12345-1’ for
key 1’ error message

I am assuming that the ‘-’ character is being ignored and that is
why I get the error.

What is the most suitable field type to use and if I change it on
the existing DB will it affect the entries there already?

David


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Mike - you have inspired me.

My original idea of having the order number as the primary key was fine until more than 1 order no per Address.

It now occurs to me that I should do as you suggest ie create a separate field for my auto incrementing INT which I should then set as Primary and have the order no field set as text and then it can contain whatever I want.

And of course there is no reason that I even need to display the primary key field at all as the list can be sorted by order no.

So if I do add that extra field set to auto increment and as Primary key will it affect the data I already have in the other fields at all?

D


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Affecting the data depends on the data the id column contains, if
there is a hyphen in it then an ‘int’ column can’t have a hyphen in
it’s data.

IMPORTANT: Use phpMyAdmin ‘or similar’ to export the database to your
desktop (I take it is a MySQL db), this way if you make any mistakes
or something happens that you don’t expect you have a copy of the
database to use for back up.

If the order number field is an integer number then set it to a field
type to suit that, you might find that an ‘int’ or ‘mediumint’ is all
that is needed… if it will only be an integer number, or a ‘varchar’
if containing a hyphen would be better suited. I wouldn’t use a text
field type unless the content actually needed a lot of text.

Info on some MySQL field types:

tinyint: 1 byte, -128 to +127 / 0 to 255 (unsigned)

smallint: 2 bytes, -32,768 to +32,767 / 0 to 65,535 (unsigned)

mediumint: 3 bytes, -8,388,608 to 8,388,607 / 0 to 16,777,215

(unsigned)

int/integer: 4 bytes, -2,147,483,648 to +2,147,483,647 / 0 to

4,294,967,295 (unsigned)

CHAR( ) A fixed section from 0 to 255 characters long.
VARCHAR( ) A variable section from 0 to 255 characters long.
TINYTEXT A string with a maximum length of 255 characters.
TEXT A string with a maximum length of 65535 characters.
BLOB A string with a maximum length of 65535 characters.
MEDIUMTEXT A string with a maximum length of 16777215 characters.
MEDIUMBLOB A string with a maximum length of 16777215 characters.
LONGTEXT A string with a maximum length of 4294967295 characters.
LONGBLOB A string with a maximum length of 4294967295 characters.

You don’t actually ‘need’ an id column but I find it has always come
to be of use in most tables, although that is not to say yours ‘needs’
one, again this depends on your schema and your needs for the database
use. If you do not use ORDER BY then the id column will be used for
the order but then you can set this to any column/s you want with the
actual query.

HTH

On Feb 7, 2011, at 8:25 PM, DeltaDave wrote:

Hi Mike - you have inspired me.

My original idea of having the order number as the primary key was
fine until more than 1 order no per Address.

It now occurs to me that I should do as you suggest ie create a
separate field for my auto incrementing INT which I should then set
as Primary and have the order no field set as text and then it can
contain whatever I want.

And of course there is no reason that I even need to display the
primary key field at all as the list can be sorted by order no.

So if I do add that extra field set to auto increment and as Primary
key will it affect the data I already have in the other fields at all?

D


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Here’s how I would set this up:

One table for accounts, call it people:

id, name, address, whatever

One table for orders, call it orders

id, date, what’s in the order, shipped, whatever else, people_id

That last one is called a foreign key, it stores a reference to the
other table’s primary key.

Using this format, you can have as many orders per person as you may
need, and you’ll be able to do interesting things with reports later
on, too.

What you’ve described in your initial design is referred to (usually
in a sneering tone) as a denormalized table. This means loosely that
you have the exact same data stored in more than one row of the same
table. For example, you have name, address, whatever exactly the same
in rows 24 and 50, and the only difference between them is the order
info.

If you look at my MyActiveRecord kit, particularly if you look at the
Generate fork of it, you’ll see one way to work with this sort of
table layout.

Walter

On Feb 7, 2011, at 2:25 PM, DeltaDave wrote:

Hi Mike - you have inspired me.

My original idea of having the order number as the primary key was
fine until more than 1 order no per Address.

It now occurs to me that I should do as you suggest ie create a
separate field for my auto incrementing INT which I should then set
as Primary and have the order no field set as text and then it can
contain whatever I want.

And of course there is no reason that I even need to display the
primary key field at all as the list can be sorted by order no.

So if I do add that extra field set to auto increment and as Primary
key will it affect the data I already have in the other fields at all?

D


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Thanks guys - the order no field is currently varchar so I guess that doesn’t need to change.

I will backup/export before I change the structure - in case it goes Tits Up

Walter I appreciate your comments about duplicate info in more than 1 entry but as there probably only 5 or 6 of these out of 100 - which once done will not be added to.

The DB is more there for static lookup than ongoing adding/changing so not really any need for interrogation for reports etc.

But point taken about linking tables in this way.

Many thanks

David


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options