Data Type Tips - Revision history

Kevlin: Data Type Data Tips moved to Data Type Tips

Kevlin — Mon, 17 Aug 2009 22:07:30 GMT

Data Type Data Tips moved to Data Type Tips

←Older revision

Revision as of 22:07, 17 August 2009

Kevlin at 22:06, 17 August 2009

Kevlin — Mon, 17 Aug 2009 22:06:46 GMT

←Older revision		Revision as of 22:06, 17 August 2009
Line 3:		Line 3:
	The names and storage mechanisms for various kinds of data have become as varied as the colors of leaves in New England in the fall. This really isn't so bad if you spend all your time programming in just one language. However, if you're like most developers, you are probably using a number of languages and technologies, which requires you to write code to convert data from one data type to another frequently.		The names and storage mechanisms for various kinds of data have become as varied as the colors of leaves in New England in the fall. This really isn't so bad if you spend all your time programming in just one language. However, if you're like most developers, you are probably using a number of languages and technologies, which requires you to write code to convert data from one data type to another frequently.

-	Many developers for one reason or another resort to using ''variant'' data types, which can further complicate matters, require more CPU processing, and are usually abused. Variant data types ~~definately~~ have their place but they are often abused. The fact is that a ~~programemr~~ should understand the strengths, weaknesses and implications of using any ~~datatype~~. One good example of where variants might be employed are functions specifically designed to accept and handle various types of data that might be passed into one or more variant parameters. One bad example of using variants would be to use them so frequently that language data type rules are effectively nullified.	+	Many developers for one reason or another resort to using ''variant'' data types, which can further complicate matters, require more CPU processing, and are usually abused. Variant data types definitely have their place but they are often abused. The fact is that a programmer should understand the strengths, weaknesses and implications of using any data type. One good example of where variants might be employed are functions specifically designed to accept and handle various types of data that might be passed into one or more variant parameters. One bad example of using variants would be to use them so frequently that language data type rules are effectively nullified.

	You can ease data type complexity when writing conversions by using an apples to apples common reference point to describe data in much the same way that many countries with varied cultures and tongues have a common, standard language to speak. The benefit of designing your code around such an idea results in modular reusable code that makes sense and centralizes data conversion to one place.		You can ease data type complexity when writing conversions by using an apples to apples common reference point to describe data in much the same way that many countries with varied cultures and tongues have a common, standard language to speak. The benefit of designing your code around such an idea results in modular reusable code that makes sense and centralizes data conversion to one place.

-	The following data types are just commonplace subset of what is available and can store just about anything~~. Abbreviations are a platform independant naming scheme used by the author~~:	+	The following data types are just commonplace subset of what is available and can store just about anything:

	:{\|		:{\|
-	~~\|b \|~~\| boolean \|\| ''true'' or ''false''	+	\|boolean \|\| ''true'' or ''false''
	\|-		\|-
-	\|~~ch \|\| char \|\| one byte (ascii~~ - ~~0 thru 255)~~	+	\|single-byte char
	\|-		\|-
-	~~\|uch \|~~\| unicode char ~~\|\| two byte (0-65535)~~	+	\|unicode char
	\|-		\|-
-	~~\|u1 \|~~\| unsigned integer \|\| ~~one byte~~	+	\|unsigned integer \|\| 8 bit
	\|-		\|-
-	~~\|u2 \|~~\| unsigned integer \|\| ~~two byte~~	+	\|unsigned integer \|\| 16 bit
	\|-		\|-
-	~~\|u4 \|~~\| unsigned integer \|\| ~~four byte~~	+	\|unsigned integer \|\| 32 bit
	\|-		\|-
-	~~\|u8 \|~~\| unsigned integer \|\| ~~eight byte~~	+	\|unsigned integer \|\| 64 bit
	\|-		\|-
-	\|~~i1 \|\|~~ integer \|\| ~~one byte~~	+	\|signed integer \|\| 8 bit
	\|-		\|-
-	\|~~i2 \|\|~~ integer \|\| ~~two byte~~	+	\|signed integer \|\| 16 bit
	\|-		\|-
-	\|~~i4 \|\|~~ integer \|\| ~~four byte~~	+	\|signed integer \|\| 32 bit
	\|-		\|-
-	\|~~i8 \|\|~~ integer \|\| ~~eight byte~~	+	\|signed integer \|\| 64 bit
	\|-		\|-
-	~~\|f \|~~\| float \|\| ~~four byte~~	+	\|float \|\| 32 bit
	\|-		\|-
-	~~\|d \|~~\| double \|\| ~~eight byte~~	+	\|double \|\| 64 bit
	\|-		\|-
-	~~\|s \|~~\| string \|\| undetermined length	+	\|string \|\| undetermined length
	\|-		\|-
-	~~\|sx \|~~\| string \|\| fixed length	+	\|string \|\| fixed length
	\|-		\|-
-	~~\|us \|~~\| unicode string \|\| undetermined length	+	\|unicode string \|\| undetermined length
	\|-		\|-
-	~~\|ux \|~~\| unicode string \|\| fixed length	+	\|unicode string \|\| fixed length
	\|-		\|-
-	~~\|bin \|~~\| unspecified binary object \|\| undetermined length	+	\|unspecified binary object \|\| undetermined length
	\|}		\|}

Jasonpsage: Consider data types carefully - especially when working with disparate systems and writing system integrations. Using a limited subset of datatypes that get the job done can be beneficial.

Jasonpsage — Sun, 09 Aug 2009 02:14:24 GMT

Consider data types carefully - especially when working with disparate systems and writing system integrations. Using a limited subset of datatypes that get the job done can be beneficial.

←Older revision		Revision as of 02:14, 9 August 2009
Line 3:		Line 3:
	The names and storage mechanisms for various kinds of data have become as varied as the colors of leaves in New England in the fall. This really isn't so bad if you spend all your time programming in just one language. However, if you're like most developers, you are probably using a number of languages and technologies, which requires you to write code to convert data from one data type to another frequently.		The names and storage mechanisms for various kinds of data have become as varied as the colors of leaves in New England in the fall. This really isn't so bad if you spend all your time programming in just one language. However, if you're like most developers, you are probably using a number of languages and technologies, which requires you to write code to convert data from one data type to another frequently.

-	Many developers for one reason or another resort to using ''variant'' data types, which can further complicate matters, require more CPU processing, and are usually abused.	+	Many developers for one reason or another resort to using ''variant'' data types, which can further complicate matters, require more CPU processing, and are usually abused. Variant data types definately have their place but they are often abused. The fact is that a programemr should understand the strengths, weaknesses and implications of using any datatype. One good example of where variants might be employed are functions specifically designed to accept and handle various types of data that might be passed into one or more variant parameters. One bad example of using variants would be to use them so frequently that language data type rules are effectively nullified.

	You can ease data type complexity when writing conversions by using an apples to apples common reference point to describe data in much the same way that many countries with varied cultures and tongues have a common, standard language to speak. The benefit of designing your code around such an idea results in modular reusable code that makes sense and centralizes data conversion to one place.		You can ease data type complexity when writing conversions by using an apples to apples common reference point to describe data in much the same way that many countries with varied cultures and tongues have a common, standard language to speak. The benefit of designing your code around such an idea results in modular reusable code that makes sense and centralizes data conversion to one place.

-	The following data types are commonplace and can store just about anything:	+	The following data types are just commonplace subset of what is available and can store just about anything. Abbreviations are a platform independant naming scheme used by the author:

	:{\|		:{\|
	\|b \|\| boolean \|\| ''true'' or ''false''		\|b \|\| boolean \|\| ''true'' or ''false''
		+	\|-
		+	\|ch \|\| char \|\| one byte (ascii - 0 thru 255)
		+	\|-
		+	\|uch \|\| unicode char \|\| two byte (0-65535)
	\|-		\|-
	\|u1 \|\| unsigned integer \|\| one byte		\|u1 \|\| unsigned integer \|\| one byte
Line 48:		Line 52:

	Now, converting and moving complex data types such as record structures, linked lists, and database tables obviously complicates things. Nonetheless, the same principles apply. Whenever you create a staging area whose layout is well defined, like the data types listed above, and write code to move data into a structure from a given source as well as the mechanism to move it back, you create valuable programming opportunities.		Now, converting and moving complex data types such as record structures, linked lists, and database tables obviously complicates things. Nonetheless, the same principles apply. Whenever you create a staging area whose layout is well defined, like the data types listed above, and write code to move data into a structure from a given source as well as the mechanism to move it back, you create valuable programming opportunities.
		+
		+	To summarize, it's important to consider what each data type offers and their implications in the language they are used in. Additionally, when considering systems integrations where disparate technologies are in use, it is wise to know how data types map between the systems to prevent dataloss.

	Most organizations are very aware of the fetters that vendor lock-in creates. By devising a common tongue for all your systems to speak in, you manufacture a powerful tool to loosen those bonds.		Most organizations are very aware of the fetters that vendor lock-in creates. By devising a common tongue for all your systems to speak in, you manufacture a powerful tool to loosen those bonds.

Kevlin at 13:15, 6 August 2009

Kevlin — Thu, 06 Aug 2009 13:15:04 GMT

←Older revision		Revision as of 13:15, 6 August 2009
Line 1:		Line 1:
-	The reserved words int, shortint, short, and smallint are a few names, taken from only two programming languages, that indicate a two byte signed integer.	+	The reserved words <code>int</code>, <code>shortint</code>, <code>short</code>, and <code>smallint</code> are a few names, taken from only two programming languages, that indicate a two-byte signed integer.

-	The names and storage mechanisms for various kinds of data have become as varied as the colors of leaves in New England in the fall. This really isn't so bad if you spend all your time programming in just one language. However if you're like most developers, you are probably using a number of languages and technologies, which requires you to write code to convert data from one data type to another frequently.	+	The names and storage mechanisms for various kinds of data have become as varied as the colors of leaves in New England in the fall. This really isn't so bad if you spend all your time programming in just one language. However, if you're like most developers, you are probably using a number of languages and technologies, which requires you to write code to convert data from one data type to another frequently.

-	Many developers for one reason or another resort to using ~~“Variant”~~ data types, which further complicate matters, require more CPU processing, and are usually abused.	+	Many developers for one reason or another resort to using ''variant'' data types, which can further complicate matters, require more CPU processing, and are usually abused.

-	You can ease data type complexity when writing conversions by using an apples to apples common reference point to describe data in much the same way that many countries with varied cultures and tongues have a common language to speak. The benefit of designing your code around such an idea results in modular reusable code that makes sense and centralizes data conversion to one place.	+	You can ease data type complexity when writing conversions by using an apples to apples common reference point to describe data in much the same way that many countries with varied cultures and tongues have a common, standard language to speak. The benefit of designing your code around such an idea results in modular reusable code that makes sense and centralizes data conversion to one place.

-	The following ~~datatypes~~ are commonplace and can store just about anything:	+	The following data types are commonplace and can store just about anything:

-	* '''b – boolean ~~– True or False~~'''	+	:{\|
-	* '''u1 - unsigned integer – one byte~~'''~~	+	\|b \|\| boolean \|\| ''true'' or ''false''
-	* '''u2 - unsigned integer – two byte~~'''~~	+	\|-
-	* '''u4 - unsigned integer – four byte~~'''~~	+	\|u1 \|\| unsigned integer \|\| one byte
-	* '''u8 - unsigned integer – eight byte~~'''~~	+	\|-
-	* '''i1 – integer – one byte~~'''~~	+	\|u2 \|\| unsigned integer \|\| two byte
-	* '''i2 – integer – two byte~~'''~~	+	\|-
-	* '''i4 – integer – four byte~~'''~~	+	\|u4 \|\| unsigned integer \|\| four byte
-	* '''i8 – integer – eight byte~~'''~~	+	\|-
-	* '''f – float – four byte~~'''~~	+	\|u8 \|\| unsigned integer \|\| eight byte
-	* '''d – double – eight byte~~'''~~	+	\|-
-	* '''s – string – undetermined length~~'''~~	+	\|i1 \|\| integer \|\| one byte
-	* '''sx – string fixed length~~'''~~	+	\|-
-	* '''us – unicode string - undetermined length~~'''~~	+	\|i2 \|\| integer \|\| two byte
-	* '''ux – unicode string – fixed length~~'''~~	+	\|-
-	* '''bin – unspecified binary object~~'''~~	+	\|i4 \|\| integer \|\| four byte
		+	\|-
		+	\|i8 \|\| integer \|\| eight byte
		+	\|-
		+	\|f \|\| float \|\| four byte
		+	\|-
		+	\|d \|\| double \|\| eight byte
		+	\|-
		+	\|s \|\| string \|\| undetermined length
		+	\|-
		+	\|sx \|\| string \|\| fixed length
		+	\|-
		+	\|us \|\| unicode string \|\| undetermined length
		+	\|-
		+	\|ux \|\| unicode string \|\| fixed length
		+	\|-
		+	\|bin \|\| unspecified binary object \|\| undetermined length
		+	\|}

-	The trick is to write code to convert your various data types to your ~~“common tongue”~~ and alternately write code to convert them back. If you do this for the various systems in your organization you will have a data type conversion code base that can move data to and from every system you did this for. This will speed data conversion tremendously.	+	The trick is to write code to convert your various data types to your "common tongue" and alternately write code to convert them back. If you do this for the various systems in your organization, you will have a data-type conversion code base that can move data to and from every system you did this for. This will speed data conversion tremendously.

-	This same technique works for moving data to and from disparate database software, accounting SDK interfaces, CRM systems and more.	+	This same technique works for moving data to and from disparate database software, accounting SDK interfaces, CRM systems, and more.

-	Now, converting and moving complex data types such as record structures, linked lists, and database tables obviously complicates things ~~- however~~ the same principles apply. Whenever you create a staging area whose layout is well defined like the ~~datatypes~~ listed above, and write code to move data into a structure from a given source as well as the mechanism to move it back, you create valuable programming opportunities.	+	Now, converting and moving complex data types such as record structures, linked lists, and database tables obviously complicates things. Nonetheless, the same principles apply. Whenever you create a staging area whose layout is well defined, like the data types listed above, and write code to move data into a structure from a given source as well as the mechanism to move it back, you create valuable programming opportunities.

-	Most organizations are very aware of the fetters that vendor lock-in creates~~, and by~~ devising a common tongue for all your systems to speak in, you manufacture a powerful tool to loosen those bonds.	+	Most organizations are very aware of the fetters that vendor lock-in creates. By devising a common tongue for all your systems to speak in, you manufacture a powerful tool to loosen those bonds.

-	The details may be in the data, but the data is stored in your ~~datatypes~~.	+	The details may be in the data, but the data is stored in your data types.
		+
		+	By [[Jason P Sage]]
		+
		+
		+	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Rstafford at 05:58, 6 March 2009

Rstafford — Fri, 06 Mar 2009 05:58:58 GMT

←Older revision		Revision as of 05:58, 6 March 2009
Line 1:		Line 1:
-	int, shortint, short, smallint are a few names taken from only two programming languages that indicate a two byte signed integer.	+	The reserved words int, shortint, short, and smallint are a few names, taken from only two programming languages, that indicate a two byte signed integer.

-	The names and storage mechanisms for various kinds of data have become as varied as the colors of leaves in New England in the fall. This really isn't so bad if you spend all your time programming in just one language. However if you're like most developers, you are probably using a number of languages and technologies which requires you to write code to convert data from one data type to another frequently.	+	The names and storage mechanisms for various kinds of data have become as varied as the colors of leaves in New England in the fall. This really isn't so bad if you spend all your time programming in just one language. However if you're like most developers, you are probably using a number of languages and technologies, which requires you to write code to convert data from one data type to another frequently.

-	Many developers for one reason or another resort to using “Variant” data types which further complicate matters, require more CPU processing and are usually abused.	+	Many developers for one reason or another resort to using “Variant” data types, which further complicate matters, require more CPU processing, and are usually abused.

-	You can ease data type complexity when writing conversions by using an apples to apples common reference point to describe data in much the same way that many countries with varied cultures and tongues have a common language ~~which~~ to speak. The benefit of designing your code around such an idea results in modular reusable code that makes sense and centralizes data conversion to one place.	+	You can ease data type complexity when writing conversions by using an apples to apples common reference point to describe data in much the same way that many countries with varied cultures and tongues have a common language to speak. The benefit of designing your code around such an idea results in modular reusable code that makes sense and centralizes data conversion to one place.

	The following datatypes are commonplace and can store just about anything:		The following datatypes are commonplace and can store just about anything:
Line 30:		Line 30:
	This same technique works for moving data to and from disparate database software, accounting SDK interfaces, CRM systems and more.		This same technique works for moving data to and from disparate database software, accounting SDK interfaces, CRM systems and more.

-	Now converting and moving complex data types such as record structures, linked lists, database tables obviously complicates things however the same principles apply. Whenever you create a staging area whose layout is well defined like the datatypes listed above, and write code to move data into a structure from a given source as well as the mechanism to move it back, you create valuable programming opportunities.	+	Now, converting and moving complex data types such as record structures, linked lists, and database tables obviously complicates things - however the same principles apply. Whenever you create a staging area whose layout is well defined like the datatypes listed above, and write code to move data into a structure from a given source as well as the mechanism to move it back, you create valuable programming opportunities.

	Most organizations are very aware of the fetters that vendor lock-in creates, and by devising a common tongue for all your systems to speak in, you manufacture a powerful tool to loosen those bonds.		Most organizations are very aware of the fetters that vendor lock-in creates, and by devising a common tongue for all your systems to speak in, you manufacture a powerful tool to loosen those bonds.

	The details may be in the data, but the data is stored in your datatypes.		The details may be in the data, but the data is stored in your datatypes.

Jasonpsage at 03:53, 3 March 2009

Jasonpsage — Tue, 03 Mar 2009 03:53:21 GMT

←Older revision		Revision as of 03:53, 3 March 2009
Line 9:		Line 9:
	The following datatypes are commonplace and can store just about anything:		The following datatypes are commonplace and can store just about anything:

-	b – boolean – True or False	+	* '''b – boolean – True or False'''
-		+	* '''u1 - unsigned integer – one byte'''
-	u1 - unsigned integer – one byte	+	* '''u2 - unsigned integer – two byte'''
-	u2 - unsigned integer – two byte	+	* '''u4 - unsigned integer – four byte'''
-	u4 - unsigned integer – four byte	+	* '''u8 - unsigned integer – eight byte'''
-	u8 - unsigned integer – eight byte	+	* '''i1 – integer – one byte'''
-		+	* '''i2 – integer – two byte'''
-	i1 – integer – one byte	+	* '''i4 – integer – four byte'''
-	i2 – integer – two byte	+	* '''i8 – integer – eight byte'''
-	i4 – integer – four byte	+	* '''f – float – four byte'''
-	i8 – integer – eight byte	+	* '''d – double – eight byte'''
-		+	* '''s – string – undetermined length'''
-	f – float – four byte	+	* '''sx – string fixed length'''
-	d – double – eight byte	+	* '''us – unicode string - undetermined length'''
-		+	* '''ux – unicode string – fixed length'''
-	s – string – undetermined length	+	* '''bin – unspecified binary object'''
-	sx – string fixed length	+
-		+
-	us – unicode string - undetermined length	+
-	ux – unicode string – fixed length	+
-		+
-	bin – unspecified binary object	+

	The trick is to write code to convert your various data types to your “common tongue” and alternately write code to convert them back. If you do this for the various systems in your organization you will have a data type conversion code base that can move data to and from every system you did this for. This will speed data conversion tremendously.		The trick is to write code to convert your various data types to your “common tongue” and alternately write code to convert them back. If you do this for the various systems in your organization you will have a data type conversion code base that can move data to and from every system you did this for. This will speed data conversion tremendously.

Jasonpsage: New page: int, shortint, short, smallint are a few names taken from only two programming languages that indicate a two byte signed integer. The names and storage mechanisms for various kinds of dat...

Jasonpsage — Tue, 03 Mar 2009 03:51:10 GMT

New page: int, shortint, short, smallint are a few names taken from only two programming languages that indicate a two byte signed integer. The names and storage mechanisms for various kinds of dat...

New page

int, shortint, short, smallint are a few names taken from only two programming languages that indicate a two byte signed integer.

The names and storage mechanisms for various kinds of data have become as varied as the colors of leaves in New England in the fall. This really isn't so bad if you spend all your time programming in just one language. However if you're like most developers, you are probably using a number of languages and technologies which requires you to write code to convert data from one data type to another frequently.

Many developers for one reason or another resort to using “Variant” data types which further complicate matters, require more CPU processing and are usually abused.

You can ease data type complexity when writing conversions by using an apples to apples common reference point to describe data in much the same way that many countries with varied cultures and tongues have a common language which to speak. The benefit of designing your code around such an idea results in modular reusable code that makes sense and centralizes data conversion to one place.

The following datatypes are commonplace and can store just about anything:

b – boolean – True or False

u1 - unsigned integer – one byte
u2 - unsigned integer – two byte
u4 - unsigned integer – four byte
u8 - unsigned integer – eight byte

i1 – integer – one byte
i2 – integer – two byte
i4 – integer – four byte
i8 – integer – eight byte

f – float – four byte
d – double – eight byte

s – string – undetermined length
sx – string fixed length

us – unicode string - undetermined length
ux – unicode string – fixed length

bin – unspecified binary object

The trick is to write code to convert your various data types to your “common tongue” and alternately write code to convert them back. If you do this for the various systems in your organization you will have a data type conversion code base that can move data to and from every system you did this for. This will speed data conversion tremendously.

This same technique works for moving data to and from disparate database software, accounting SDK interfaces, CRM systems and more.

Now converting and moving complex data types such as record structures, linked lists, database tables obviously complicates things however the same principles apply. Whenever you create a staging area whose layout is well defined like the datatypes listed above, and write code to move data into a structure from a given source as well as the mechanism to move it back, you create valuable programming opportunities.

Most organizations are very aware of the fetters that vendor lock-in creates, and by devising a common tongue for all your systems to speak in, you manufacture a powerful tool to loosen those bonds.

The details may be in the data, but the data is stored in your datatypes.