I'm researching the data types of the field of SAP's data table.
I realized that the fields that only store numbers are sometimes varchar or char data types. e.g., KUNNR(Customer Number) and BUKRS(Company Code) are character data types.
What is the objective or benefit of defining the data type of the fields to varchar/char instead of int when determining the field's data type that only contains numbers by its name's definition?
edit: SAP has "numc" data type and for numeric text and "INT1/2/4/8" data type for interger but use char/varchar for Customer Number or Company Code instead. Please help me if you have the idea why they use char data type for the above cases. I'm now trying to create data schema by referencing SAP's data schema.
Pages that referencing details of SAP's table/fields:
http://www.saptables.net/
https://sapstack.com/
Companies in global supply chain exchanges their transaction data through Electronic Data Interchange(EDI). The data is often variable-length XML or something similar. SAP mainly uses varchar to efficiently use the data for their application. The XML message data for transaction vary from business to business; sometimes number sometimes charcter but required to handle and save to it the database.
Related
I have a flat CSV file and some fields contain a value like "1.8e-5, 8.139717345049093e-39" (exponent or scientific numbers). I need to store this value in a SQL real data type field (not float). But the maximum exponent supported by real is e-38.
But I need a mechanism to convert this string field to a real number through SSIS. Basically the e-39 or smaller values should be replaced as 0. and the rest should be stored properly.
I tried setting the data type to DT_R4 in flat file connection field mapping and that didn't help. I tried casting it to DT_R4 through a derived column and that didn't help too. When I check through Data Viewer still the value has the unsupported exponent value and it fails when I insert it to the SQL table.
I have an Excel CSV file with a Barcode column that has data that looks like this: 5.06E+12 - it has a decimal number(5.06), letter(E) and symbol(+).
When I try to edit this in Excel, the number changes to 5060190000000.
When storing this type of data to my SQL Server database, what should the data type be of my Model's Barcode property?
Try to pick the most appropriate data type. If you're using actual product barcodes, a little research indicates that they're likely International Article Numbers.
Since they're really strings of 13 digits, a char(13) would probably be the most appropriate data type to store this data. Don't just default to varchar(50) because that's "big enough" - think of the length specification as free validation.
This is called E notation which is a variation of scientific notation. The number in question is an integer, but is abbreviated.
5.06 * 10^12 = 5060190000000
Thus, your value should be stored as an integer large enough to store your number.
Your value should be stored as a varchar long enough to fit the length of potential values.
My requirement is to store a list of emailIds in a single column, What would be the best data type to do so? My columns are like EmailTo , EmailCC, EmailBCC in which I would require storing the list of Ids. Also , help me with the size of the datatype.
I am using SQL server.
It's good to go with NVARCHAR(320) - 64 characters for local part + # + 255 for domain name.
You can refer this for more information.
For email , please use data type as VARCHAR[(n)]
According to defination in MSSQL Server 2008
VARCHAR[(n)] : Describes a variable-length string of single- byte characters.In contrast to the CHAR data type, the values for the VARCHAR data type are stored in their actual length. This data type has two synonyms: CHAR VARYING and CHARACTER VARYING
In building database , I used VARCHAR(45) ,this was working fine for email purposes.
The best data type to store a list (any kind of a list, not just e-mail IDs) is a table. Simple table.
For example, if it is a list of integers, the table would have an int column.
This is what RDBMS is for - they are designed to store data in a bunch of tables.
In your case you'd have several tables: EmailsTo, EmailsCC, EmailsBCC. The structure of your tables would depend on what your EmailID is, what type it is and what other related information (columns) you may need.
Seems Datatype Issue to me.To answer your question ,in my view VARCHAR(MAX) is the highest that can store up-to 8k characters or may be even more if you cast it, but that would not be the correct approach to do.
What you can do is to create a COMMON GROUP and enlist all the email id's to whom you want to send emails. This wont even occupy much of your Datatype space and all peoples can be included within that group as per your comments since you told you require it for sending emails to people.
I have a column of varchar(10) called TITLE. Except for the first row, which contains the column header, the rest of the column happens to be all integers so I wanted to change the datatype to int.
ALTER TABLE X
ALTER COLUMN TITLE int
I get an error when converting the first row, which is the column header: "Conversion failed when converting the varchar value 'TITLE' to data type int.
So, how do I convert the data type for all rows, except the column header?
The short answer is No, you cannot mix data types in a single SQL column. Data types need to be consistent for things like sorting, building indexes, etc.
You could possibly use another table to store various column headers, or another column in the same table.
Using a NoSQL solution such as MongoDB might be an approach, depending on the type of data you're storing. These solutions allow you to be a lot more flexible with the schema, which can even differ per document.
Nope sorry you cannot have multiple data types on the same column.
Data types
You don't. A column isn't a collection of independent variables that can each have their own type. Everything in a column has the same type. If you're trying to do this, then your schema isn't likely what it should be. If you post a little more detail, you can likely get some answers with an improved schema.
You can't mix'n'match data types within a column. You can use fuzzy data types like VarBinary or XML and interpret them as you please.
OTOH, you can use sp_addextendedproperty to store column titles and other extraneous bits of fluff.
Hi I was wondering when I should use the different data types. As in in my table, how can I decide which to use: nvarchar, nchar, varchar, varbinary, etc.
Examples:
What would I use for a ... column:
Phone number,
Address,
First Name, Last Name,
Email,
ID number,
etc.
Thanks for any help!
As a general rule, I would not define anything as a "number" field if I wasn't going to be doing arithmetic on it, even if the data itself was numeric.
Your "phone" field is one example. I'd define that as a varchar.
Varchar, Integer, and Bit cover 99% of my day to day uses.
The question really depends on your requirements. I know that's not a particularly satisfactory answer, but it's true.
The n..char data types are for Unicode data, so if you're going to need to use unicode character sets in your data you should use those types as opposed to their "non-n" analogs. the nchar and char type are fixed length, and the nvarchar and varchar type can have a variable length, which will effect the size of the column on the disk and in memory. Generally I would say to use the type that uses the least disk space but fits for your needs.
This page has links to the Microsoft descriptions of these datatypes for SQL Server 2005, many of which give pointers for when to use which type. You might be particularly interested in this page regarding char and varchar types.
A data type beginning with n means it can be used for unicode characters... eg nVarchar.
Selection of integers is also quite fun.
http://www.databasejournal.com/features/mssql/article.phpr/2212141/Choosing-SQL-Server-2000-Data-Types.htm
The most common data type i use is varchar....
The N* data types (NVARCHAR, NCHAR, NTEXT) are for Unicode strings. They take up two times the space their "normal" pendants (VARCHAR, CHAR, TEXT) need, but they can store Unicode without conversion and possible loss of fidelity.
The TEXT data types can store nearly unlimited amounts of data, but they perform not as good as the CHAR data types because they are stored outside of the record.
THE VARCHAR data types are of variable length. They will not be padded with spaces at the end, but their CHAR pendants will (a CHAR(20) is always twenty characters long, even if if contains 5 letters only. The remaining 15 will be spaces).
The binary data types are for binary data, whatever you care to store into them (images are a primary example).
Other people have given good general answers, but I'd add one important point: when using VARCHAR()s (which I would recommend for those kinds of fields), be sure to use a length that's big enough for any reasonable value. For example, I typically declare VARCHAR(100) for a name, e-mail address, domain name, city name, etc., and VARCHAR(200) for an URL or street address.
This is more than you'll routinely need. In fact, 30 characters is enough for almost all of these values (except full name, but a good database should always store first and last name separately), but it's better than having to change data types some day down the road. There's very little cost in specifying a higher-than-necessary length for a VARCHAR, but note that VARCHAR(MAX) and TEXT do entail significant overhead, so use them only when necessary.
Here's a post which points out a case where a longer-than-necessary VARCHAR can hurt performance: Importance of varchar length in MySQL table. Goes to show that everything has a cost, though in general I'd still favor long VARCHARs.