I know this question has been asked more than once here, but I couldn't find a solution.
We are using a database where we are storing the facebook id as a BIGINT(20).
create table users(
fb_id bigint(20) NOT NULL,
user_name varchar(30) NOT NULL,
CONSTRAINT uk_name unique (user_name),
CONSTRAINT pk_fb_id primary key (fb_id)
)ENGINE=INNODB;
But the PDO engine of PHP can insert only the max integer value of PHP, i.e. 2147483647.
$stmt->bindParam(':fb_id', $this->fb_id, PDO::PARAM_INT);
This, I understand, is quite obvious since we are limited by the maximum value of integer in PHP. I tried to use the string -
$stmt->bindParam(':fb_id', $this->fb_id, PDO::PARAM_STR);
but still it doesn't work.
I want to know if there could be a workaround to store it as bigint.
We are using a database where we are storing the facebook id as a BIGINT(20).
Why oh why are you doing that?
I think general consensus is that Facebook ids should not be saved as numeric types, but as strings instead. Saving them as something numeric does not yield any advantages whatsoever – but several disadvantages.
Related
I have a MySQL database with a bigint field but when I'm using on cakephp the number 697483533702444 is being displayed as 2147483647
You need to either use a 64bit version of PHP or store your data in the database as a CHAR(20) or VARCHAR(20)
I cant write comment (missing points), but I experienced some Problems with signed and unsigned Integers and quite similar results. Please try changing signed and unsigned in the database.
Problem:
I have the following table in MySQL.
For this example lets say that there is (and always will be) only one person in the world called "Tom" "Bell". So (name, surname) is the PRIMARY KEY in my table. Every person has his salary, an unsigned integer.
CREATE TABLE IF NOT EXISTS `user` (
`name` varchar(64) NOT NULL DEFAULT 'Default_name',
`surname` varchar(64) NOT NULL DEFAULT 'Default_surname',
`salary` int(10) unsigned NOT NULL DEFAULT '0',
UNIQUE KEY `id` (`name`,`surname`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Whenever I insert a row using a PHP script I want my function to return the primary key of the inserted row (an array key=>value).
From PHP context I do not know what the primary key of table 'user' consists of and I do not always need to set all primary key values (example 2, very stupid, but possible).
I can add another argument to my insert function (for example I could pass the table name, in this case "user").
If this matters, I am using PDO (php data objects) to connect with my MySQL database.
Example 1:
$db->insert('INSERT INTO `user` (`name`,`surname`,`salary`) VALUES ('Tom','Bell','40');');
should return an array:
$arr = ['name' => 'Tom', 'surname' => 'Bell'];
Example 2:
$db->insert('INSERT INTO `user` (`name`,`salary`) VALUES ('Nelly','40');');
should return an array:
$arr = ['name' => 'Nelly', 'surname' => 'Default_surname'];
Disclaimer & other information:
I know this is not a well-designed table, I could use an auto_increment id column to make it much easier and probably more efficient as well. This is just an example to show the problem without having to explain my project structure.
Without loss of generality: Using functions like "getLastInsertId()" or "##identity" will return 0, I guess the reason is because the table does not have an auto_increment column.
What have I tried? Nothing (other than things stated in point 2 (which I was certain it wouldn't work) and searching for a solution).
There aren't "nice" ways around this problem. One of the reasons for having an auto_increment is to avoid having problems like you described.
Now, to avoid my answer to be one of those that take into account only half the picture - I do realize that sometimes you inherit a project or you simply screw up during initial stages and you have to fix things quickly.
To reflect on your example - your PK is a natural PK, not a surrogate one like auto_increment is. Due to that fact it's implied that you always know the PK.
In your example #1 - you inserted Tom Bell - that means you knew the PK was Tom Bell since you instructed MySQL to insert it. Therefore, since you knew what the PK was even before insert, you know how to return it.
In your example #2 you specified only a part of the PK. However, your table definition says thtat default values for both name and surname are Default_surname. That means, if you omit either part of the PK, you know it'll assume the default value. That also means you already know before insertion what the PK is.
Since you have to use a natural PK instead of a surrogate, the responsibility of "knowing" it shifts to you instead of RDBMS. There is no other way of performing this action. The problem becomes even more complex if you allow for a default value to become null. That would let you insert more than 1 Tom with null as surname, and the index constraint wouldn't apply (null is not equal to null, therefore (tom, null) is not equal to (tom, null) and insert can proceed).
Long story short is that you need a surrogate PK or the auto_increment. It does everything you require based on the description. If you can't use it then you have a huge problem at your hands that might not be solvable.
Question: Stated in title
Project: My PHP Mafia/Mobsters Strategy Game
Reason for Asking: I'm unsure how I would word this question into a somewhat relevant Google search.
I would like to know which MySql variable type I should use for an array. I will explode this array into an ID list including all people in that players mob.
EXAMPLE MYSQL DATA BELOW:
PlayerId -------- Mob //Lables
134 ------------- '23','59','12','53','801' //Values
This will then be exploded using explode() in PHP into a bunch of ints containing the IDS of players in that persons mob.
I would like the mob field to have an unlimited character length so that players can have HUGEE mobs.
I think I may be able to simply use longtext or the set type but I'm not completely sure. I don't want any errors later on once I release the game and I want my methods to stay clean and correct.
Thank you so much for taking the time to read this, I hope you can help. :)
You should create a table that associates players with mobs:
CREATE TABLE PlayerMobs (
PlayerId INT UNSIGNED NOT NULL,
MobId INT UNSIGNED NOT NULL,
FOREIGN KEY (PlayerID) REFERENCES Players (PlayerID),
FOREIGN KEY (MobID) REFERENCES Mobs (MobID)
);
And then join it with your other tables in queries as required.
I have added FOREIGN KEY constraints to ensure that only valid PlayerID and MobID values exist in the PlayerMobs table, but note that these constraints currently only work with the InnoDB storage engine.
You can try
CREATE TABLE PlayerMobs (
PlayerId INT UNSIGNED NOT NULL,
MobId Text UNSIGNED NOT NULL);
I did this a very long time ago, but I happened to come across the question when browsing through my account.
There aren't any specific "mobs." Your "mob" is basically like a friends list. It's not a group. It's just a bunch of people connected to you.
I believe I simply made a row for "mob members" and just put the other players ids, separated by commas, then in the PHP I exploded the string with a comma as the delimiter.
I am in the process of migrating a large amount of data from several databases into one. As an intermediary step I am copying the data to a file for each data type and source db and then copying it into a large table in my new database.
The structure is simple in the new table, called migrate_data. It consists of an id (primary key), a type_id (incremented within the data type set), data (a field containing a serialized PHP object holding the data I am migrating), source_db (refers to the source database, obviously), data_type (identifies what type of data we are looking at).
I have created keys and key combinations for everything but the data field. Currently I have the data field set as a longtext column. User inserts are taking about 4.8 seconds each on average. I was able to trim that down to 4.3 seconds using DELAY_KEY_WRITE=1 on the table.
What I want to know about is whether or not there is a way to improve the performance even more. Possibly by changing to a different data column type. That is why I ask about the longtext vs text vs blob. Are any of those more efficient for this sort of insert?
Before you answer, let me give you a little more information. I send all of the data to an insert function that takes the object, runs it through serialize, then runs the data insert. It is also being done using Drupal 6 (and its db_query function).
Any efficiency improvements would be awesome.
Current table structure:
CREATE TABLE IF NOT EXISTS `migrate_data` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`type_id` int(10) unsigned NOT NULL DEFAULT '0',
`data` longtext NOT NULL,
`source_db` varchar(128) NOT NULL DEFAULT '',
`data_type` varchar(128) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `migrated_data_source` (`source_db`),
KEY `migrated_data_type_id` (`type_id`),
KEY `migrated_data_data_type` (`data_type`),
KEY `migrated_data_id__source` (`id`,`source_db`),
KEY `migrated_data_type_id__source` (`type_id`,`source_db`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 DELAY_KEY_WRITE=1;
The various text/blob types are all identical in storage requirements in PHP, and perform exactly the same way, except text fields are subject to character set conversion. blob fields are not. In other words, blobs are for when you're storing binary that MUST come out exactly the same as it went in. Text fields are for storing text data that may/can/will be converted from one charset to another.
I need to create a database schema for storing user information (id, name, p/w, email address ...etc). I have always picked arbitrary amounts when sizing these fields. With this said, I have two questions:
1) What are good sizes for these fields? I am sure there is a maximum email address length for example...etc.
2) I now need to store user mailing addresses for credit card purchases, including international mailing addresses. This is an area I do not want to pick arbitrary sizes.
Does anyone know of a good schema for either? Is there a project for this maybe?
Thanks!
Also consider which db engine you will use and whether the primary key will be email, rowid, or an arbitrary number. I typically save passwords on a second table called "security" using a hash as suggested above. Here's an example.
CREATE TABLE IF NOT EXISTS `users` (
`user_id` varchar(255) NOT NULL,
`active` char(1) default 'Y',
`created_date` INTEGER UNSIGNED default 0,
`email` varchar(255) default NULL,
`first_name` varchar(255) default NULL,
`last_name` varchar(255) default NULL,
`modified_date` INTEGER UNSIGNED default 0,
PRIMARY KEY (`user_id`, `active`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
I'll give you a hand with part 1. In general you shouldn't stress very much about the size of your MySQL DB fields, you don't have to get the number exactly right -- just make sure that someone with a reasonable answer doesn't get their data truncated.
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`username` varchar(255),
`email` varchar(255),
`password` char(256)
Notice that for password I have a 256bit character field instead of a varchar field. Thats because you should never store plain text passwords in a database. Instead, you should always store the password in a hashed format with some sort of unique "salt" for that password. You can find some tutorials online, and the length of the password field depends on the type of hashing you use on the password.
This is a pretty tough question to answer, because in my opinion there is a difference between what you "should" allow and what is considered allowable by the IETF.
The maximum allowable email address is 256 characters which includes a slash at the beginning and end of the email address (therefore only 254 usable characters). You can find detailed information about it on this page by Dominic Sayers.
But will any legitimate user actually have an email address that long?
As for street addresses, I don't believe that is specified anywhere, however according to the world's longest website the longest street name is 72 characters. Therefore if you made the field 100 characters you would have more than enough room for the street address.
You don't have to be really too concerned with getting everything 100% correct, you should be more concerned with the quality of the data which you decide to accept into the database (make sure it is valid/clean). Also provide clear rejection messages if someone does enter something which is simply too long -- and make sure there is an easy method for the owner of the website to be contacted if that does happen.
One thing I'd like to note, NoSQL is all the rage right now, and it uses schema-less database engines, for example MongoDB and CouchDB. It is not the best solution for everything, however if you are very concerned about having the correct schema, possibly a schema-less database might be a good option.