I have a rails app and one of my tables has a big integer key in mysql. I am looking to archive some of the data from the mysql table in mongodb, but am not sure which type to use in field statement within mongoid to store the orignal_id, I have no intention to change the id that mongoid will generate, I am not looking to change the _id field of the new table.
If you are using mongoid you can define the field as integer. Integers are instance objects of a Fixnum or a Bignum class in Ruby. If any operation on a Fixnum exceeds its range, the value is automatically converted to a Bignum.
Your only choice for numeric values in JavaScript is Number. The largest integer that can safely be represented is: 9007199254740991. According to the mysql docs, the maximum bigint is 9223372036854775807, twice that if unsigned.
Maybe you should save it as a string if it's important to maintain fidelity.
I do not use rails, but NumberLong may exist in Rails too. This is a wrapper for 64bit integers. With a unique index you may have similar results, as in MySQL.
Related
I have a table with lots of redundant data.
I'd like to change some of the VARCHAR values to some sort of "AUTO_LOOKUP" data type, that automatically maintains and resolves values from a look-up table.
MySQL does this partially with the ENUM datatype, but it requires ahead-of-time definition of all known values. I would like the list of values to dynamically grow.
Does this exist?
Related questions:
Similar concept, using a custom datatype in Derby: User-defined types in Apache Derby as ENUM replacements
Similar concept, but handling 100% in the client application (I want it handled in the database instead): Ways to save enums in database
Yes, it's called a foreign key, and it's supported by virtually all relational databases.
You define your set of varchars in a lookup table, with one row per value. Associated with the string is a more compact primary key, typically an auto-increment integer.
Then in your large table, just reference the entry in the lookup table by integer.
In my tables I use an auto-increment PK on tables where I store for example posts and comments.
I don't want to expose the PK to the HTTP client, however, I still use it internally in my API implementation to perform quick lookups.
When a user wants to retrieve a post by id, I want to have an alternate unique key on the table.
I wonder what is the best (most common) way to use as type for this field.
The most obvious to me would be to use a UUID or GUID.
I wonder if there is a straightforward way to generate a random numeric key for this instead for performance.
What is your take on the best approach for this situation?
MySQL has a function that generates a 128-bit UUID, version 1 as described in RFC 4122, and returns it as a hex string with dashes, by the custom of UUID formatting.
https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid
A true UUID is meant to be globally unique in space and time. Usually it's overkill unless you need a distributed set of independent servers to generate unique values without some central uniqueness validation, which could create a bottleneck.
MySQL also has a function UUID_SHORT() which generates a 64-bit numeric value. This does not conform with the RFC, but it might be useful for your case.
https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid-short
Read the description of the UUID_SHORT() implementation. Since the upper bits are seldom changing, and the lower bits are simply monotonically incrementing, it avoids the performance and fragmentation issues caused by inserting random UUID values into an index.
The UUID_SHORT value also fits in a MySQL BIGINT UNSIGNED without having to use UNHEX().
Create a table in Access with a field that is a long int. Set the field to be indexed (either type). Create one record with value of 1. Then create a query looking for all records in that table with value less than 5. Works. Now search for records with value less than 5.5. Fails.
Should this be reported to Microsoft? I can't find a way around this, other than removing the index.
It's the index. It expects an integer while 5.5 on its own seems to be casted to a Decimal.
So, when setting the filter, first convert using any function that always will return an integer:
Int, Fix, CInt, CLng, CByte, even CBool
I have an old database table with column, which type is BIGINT. There's a lot of stored procedures and views that use that table and that column.
For some reason I need to change the type of that column to NUMERIC(38,0).
Is it safe to do it? Should I cast in any stored procedure and view existing BIGINT to NUMERIC(38,0)?
According to me numeric data type is identical with decimal which represents a fixed precision number, which will scale numeric data from -10^38 +1 through 10^38 –1
I don't think that the number types you mention are using fixed precision number and therefore BIGINT is probably the most efficient way to store the number especially if you want to perform some computation in your application.
I don't see really any use for computation with those number and therefore you may even use a string of appropriate length which requires more space in the database but you may be able to allow grouping characters in the numbers.
using BIGINT datatype instead of string you can create efficient indexes.
As you write you're already using numeric datatype and therefore if you upgrade to SQL 2008R2 / 2012 you should consider switching to BIGINT as you don't need fraction in your number. The BIGINT data type is intended for use when integer values might exceed the range that is supported by the int data type.
EDIT:
You can change the data type from BIGINT to NUMERIC(38,0) but be ensure that a Arthimetic overflow error shouldn't occur while converting.
Yes, it is.
According to this table on MSDN an numeric(38,0) has an higher capacity than a bigint.
I calculated the maximum values based on the numbers in the matrix:
9223372036854775808 (bigint, 2^63-1, 8 bytes)
1000000000000000000000000000000000000000 (numeric(38,0), 10^38–1, 17 bytes)
I'm making a symfony2 project using Doctrine 2 and i'm using Annotations to map my entities to a MySQL database.
I have read doctrine 2 documentation and it says that the length attribute applies only to the string type.
So my question is, is there a way to set a specific length (so no smallint, bigint and so on...) of an integer column through annotations (other than columnDefinition) and if not...why there isn't any? In Doctrine 1 i could specify a certain specific length for integer types
Because Doctrine is created for manipulating data using itself. And it is not care how this data will be displayed by another programs. But length definition for numeric values exist only for convenient displaying data in DB-managers (mostly for cli mysql client).
In Doctrine you also cannot create triggers for the same reason. You can implement such trigger with doctrine.