I've been running a small web-based experiemnt using Facebook UIDs to verify unique users.
Recently I've discovered that UIDs can be bigger than I realised among some users, so my int-based system is now inadequate and I need to convert to bigint.
I can't risk losing the results I already have, but need to convert the table so that the index containing the uid is now bigint. Are there any particular issues changing the type of an index column, and would it be as simple as:
ALTER TABLE breadusers MODIFY userid bigint;
?
In theory this should be absolutely fine, although it the data really matters, I presume you have a recent backup anyway in case something goes awry.
That said, I'd probably be tempted to store the Facebook UID as a string (i.e.: in a VARCHAR field) and simply have a generic auto-incremented ID field. Then again, that's an answer to a different question. :-)
For the Facebook UID part, I would suggest you to go for BIGINT(64).
Here is the answer from Facebook Blog:
https://developers.facebook.com/blog/post/45/
Related
I need to store some social ids (facebook/google/twitter user id, facebook place id, ecc..) in my MySQL DB. I found a lot of questions about this here on stackoverflow, but I didn't find a satisfactory answer. For example you can't be sure 100% that facebook id will always be a unsigned bigint, from facebook documentation the facebook id is described as "numeric string". Google id seems one digit bigger than bigint.
I believe that an index on a varchar column is slower than an index on a bigint column, for this reason I thought that using bigint, when possible, would be better than varchar. But I realized that you can store a varchar as a binary with the appropriate attribute.
For this reason I was thinking about use a varchar for all these social ids and (since the ordering is not an issue) store it as binary (attribute=binary), this because I need a fast index on them.
what's your thoughts: is this a good and fast solution?
Thanks
I use varchar. You are right about the differences, but even more importantly, there is no guarantee that the current type will stay the same. For instance, Facebook changes the size in the past and they mentioned somewhere that they may include chars in it.
An index is an index, if done right, there is no need to worry about its performance. No real difference between an index on numbers or varchar.
bigint + INDEX KEY + INNODB = Fast
I am concerned with the performance of a database table i have to store data related
with a customer survey application.
I have a database table storing customer responses from a survey. Since the survey questions change according to customer i though instead of defining
the table schema using each questionid as column to define it as as follows
customerdata(customerid varchar,
partkey varchar,
questionkey varchar,
value, varchar,
version, int,
lastupdate, timestamp)
Where:
partkey: is the shortcode of the part (part1,part2...)
questionkey: is the shortcode of the question
e.g age, gender etc
since some customers fill the survey twice, thrice etc i have added the version column.
With this design customerid,partkey,questionkey and version are primary keys.
i am concerned about the performance with such design. Should i define the other primary keys as indexes ? Would that help ? So far for 30 customers i have 7000 records. I expect to have maximum 300-500. What do you think ?
Sounds like a pretty small database. I doubt you'll have performance issues but if you detect any when querying on partkey, questionkey, or version later on you can always add one or more indexes to solve the problem at that time. There's no need to solve a performance problem you don't have and probably never will have.
Performance issues will arise only if you have to perform time-sensitive queries that don't use the customerid field as the primary filter. I suspect you'll have some queries like that (when you want to aggregate data across customers) but I doubt they'll be time-sensitive enough to be impacted by the one second or less response time I would expect to see from such a small collection of data. If they are, add the index(es) then.
Also, note that a table only has a single PRIMARY KEY. That key can use more than one column, so you can say that columns customerid, partkey, questionkey, and version are part of the PRIMARY KEY, but you can't say their all "primary keys".
rownumber-wise, i have experienced mysql database with over 100.000 rows and it runs just fine so you should be okay.
although it's a different case if you run complicated queries, which depends more on database design rather than row numbers.
I'm using Google App Engine and storing users. Before, I was using MySQL with an auto-incrementing int for my userId field, but now GAE auto generates a key for each new entity I store, such as g5kZXZ-aGVsbG93b3JsZHIKCxIEVXNlchgNDA, but they also automatically generate an auto-incrementing ID int too.
Which one should I use in my client code to store as the userId? Are there any advantages to using the long key that GAE generates, or is using the small int ID the same thing in terms of performance and look ups? Are there any advantages to one over the other, or is there practically no difference?
Edit: Sorry my question was not clear enough. Here's what I'm asking:
It's not about length, but does having the lookup key put me a step ahead of not having it? Because if I wanted to look up a user, I'd have to look him up by email, but now that I have the key for that row in the "table", does this give me any sort of advantage?
Either one is fine, there's no performance difference between using a long string of letters or a short one to identify users.
Remember that the generated entity ID is not guaranteed to be a monotonically increasing value.
I use id's for almost all my tables, you never know when they come handy. But today I read this...
Be extra careful to make sure that, according to convention, your ‘id’ column (or primary key) is:
char(36) and never varchar(36)
CakePHP will work with both definitions, however you will be sacrificing about 50% of the performance of your DB (MySQL in particular). This will be most evident in more complicated SELECT’s, which might require some JOIN’s or calculations.
I wonder... why even use something text-based, when you only have to save integers? I care a great deal about using the right formats for the right content, so I wonder if char gives any performance improvements over integers?
I would strongly suggestest using ints. I am doing some modelling for my thesis and I work on large datasets. I had to create a table with about ~70.000.000 rows. My primary key was varchar + int. At the beginning one cycle of creating 5-digit number of rows took 5 minutes, soon it became 40. Dropping the primary key fixed my performance issue. I guess that it is because ensuring uniqueness and it was becoming more and more time consuming. I had no similar issues when my primary key was int.
it is personal experience though, so maybe someone can give more theoretic and reliable answer.
char doesn't give any improvement over integer. But it's useful when you need to prevent users from knowing or tampering with other rows that you don't want them to.
Let's say each user have a profile picture with the naming /img/$id.jpg (the simplest case, since you don't have to store any data in DB for this information. Of course, there are other ways) If you use integer, someone can loop through all profile pictures that you have. With UUID, they can't.
When you have a lot of records, the auto increment int is better for performance. You can put the uuid in another field (secret_key, for example).
My question is more advisory than technical.
I'm writing a Facebook app in which I am fetching some information about the user, including facebook_id.
I was wondering if I should keep the user id as INT or VARCHAR in the MySQL database?
Facebook uses 64-bit integers (bigint) for their user ids. So you use Bigint UNSIGNED in MySQL.
"As a reminder, in the very near future, we will be rolling out 64 bit user IDs. We encourage you to test your applications by going to www.facebook.com/r.php?force_64bit and create test accounts with 64 bit UIDs."
Edit: Facebook usernames is not the same thing as the user id. The username is of course varchar but will not be returned as the id.
Although unlikely, facebook could change the format of their ID's, so to make it future proof, I'd use a varchar.
similar question to: Facebook user_id : big_int, int or string?
"I would not use a string. That makes comparisons painful and your indexes clunkier than they need to be."
To quote facebook's upgrade notes regarding graph API v2.0 (effective May 2015):
All IDs are strings. In v1.0, IDs were often large numbers.
Which (to me) implies that userids are not guaranteed to be numbers. In fact, facebook recommend that you use strings:
https://developers.facebook.com/docs/graph-api/reference/v2.2/user#fields
Name:id
Description: id The id of this person's user account.
This ID is unique to each app and cannot be used across different apps(...)
type: string
Although I must admit I've never seen an alphanumeric id.
Use BIGINT(64) to store Facebook User IDs.
Here you go: https://developers.facebook.com/blog/post/45/
For new data types, as they are grahp obj ID, I believe it is safe to save them as BINT.
However, for old "id", e.g. pic, save them as string (you can easily see that they are in the format xxxxxx_xxxxxxxx)
I'd use INT, because it's not so big. Searching in INT is faster and betterfor ordering