Tag Info

New answers tagged

1

Zip codes should be stored as text, as some start with 0 (screwing up formatting/sorting) and there is no reason to do math on them. Also, if you want to store global postal codes, they often contain letters. Phone numbers are a maybe for text, especially if there might be extensions. Or you want to store numbers like 1-800-GOT-JUNK. There's no reason to do ...


4

Your colleague is correct that it is easier to simply not think about it and just store everything as a varchar. But this comes at a large cost in terms of space requirements, performance, flexibility in querying data, and most importantly, lack of data integrity. This is not just a one-time cost; it is paid repeatedly over the lifecycle of the ...


3

There are several situations in which it's better to represent numbers using some kind of numeric data-type. It's a little more efficient, but that's just the beginning. You get support for built-in arithmetic using SQL operators without performing type conversions at run time. Not only do type conversions slow things down, but they can result in numerous ...


4

Size is one consideration. An int can hold up to -2,147,483,648 in four bytes. A char will need 11 bytes to hold the same value. There are built-in functions to manipulate the various data types. DATEADD() and DATEDIFF() are two examples. This will not be possible with date-stored-as-text. Constantly CASTing back and forth will not make for efficient ...


0

There are different data types in sql to store the data. if the all data are same then varchar is good to store. but in the future, you need the operation on the data, you can't because of limited functionality. better to go with the data type of data.


0

You can use Small Time Stamp (auto)


1

I would use Decimal(4,2) if you are confident that 99.99 is the max value. Decimal(4,2) will consume 2 bytes while decimal(5,2) will consume 3 bytes but give you a safety net if the value were to exceed 99.99; it's up to you how confident your data set will stay under 100.


1

If you have Oracle Database Release 12c Release 1 (12.1.0.2) then you can store JSON in the database in a VARCHAR2, CLOB, or BLOB column, and then query it in SQL using JSON path expressions (analogous to XPath expressions for XML). You can use SQL functions json_value, json_query, and json_table, and SQL conditions json_exists, is json, is not json, and ...


0

Microsoft's Jim Hogg has responded to this issue with the following: There are pros and cons. On the pro side, it seems like a good way to avoid some errors - having to check a (signed) int has value > 0. And I would also venture that many uses of int in fact relate to counts that should never be negative anyway. On the question of doubling max row ...


4

If possible, just store the first value It doesn't look like you need to store two numbers at all. If these are like tax years, i.e. "2014/2015 financial year", you only need to consistently store one part. If you store 2014, your app knows it's the academic year beginning in 2014. So it can display "2014/2015 Academic Year" with no ambiguity. If you ...


2

You could use two smallint columns: create table foo ( from_year smallint not null, to_year smallint not null, check (from_year = to_year - 1 and from_year >= extract(year from current_date)), unique (from_year, to_year) ); insert into foo values (2014,2015);


0

If you just want to store the coordinates, for later searching, your best bet is to convert from degrees-minutes-seconds to decimal degrees, and store as DECIMAL. Here is an answer giving mysql functions that do that conversion, in both directions. If you want to do more complex things like "Is this point within the constellation Orion" then you probably ...



Top 50 recent answers are included