Right up until procedures change and the identifier has changed from an integer only data type to something that starts containing characters. There's so many different types of UPCs out there, for example, that a company can switch from an integer only type of UPC to something that contains letters.
I'd err on the side that if there is even the hint that something in the real world could change to what my schema isn't going to allow for, then, make it as open-ended as possible, even going as far as changing the field to a BLOB and have the softwares future functionality be able to store the exact image that was scanned in. On Thu, Dec 20, 2018 at 10:44 AM Chris Locke <sql...@chrisjlocke.co.uk> wrote: > > Just because something doesn't have to be calculated, means that it has > to be stored as text. > > Sorry - forgot a 'doesn't'. > Just because something doesn't have to be calculated, doesn't mean that it > has to be stored as text. > > On Thu, Dec 20, 2018 at 3:42 PM Chris Locke <sql...@chrisjlocke.co.uk> > wrote: > > > Just because something doesn't have to be calculated, means that it has > to > > be stored as text. > > Its usually recommended to set the column affinity to the type of data > > you're storing. If you're storing a number (and a model number is a > > numeric number) then it should be stored in a numeric field. If your > model > > number has punctuation, then yes, a text field is required. > > Its up to the application (although some would also argue the database) > to > > validate data input, ie, ensure numeric data was inputted into a numeric > > field. > > > > On Thu, Dec 20, 2018 at 3:31 PM James K. Lowden < > jklow...@schemamania.org> > > wrote: > > > >> On Wed, 19 Dec 2018 10:55:11 +0000 > >> Chris Locke <sql...@chrisjlocke.co.uk> wrote: > >> > >> > Fields with '_no' are read as 'number' and so should be a number. > >> > OK, that doesn't always work for 'telephone_no' (they usually start > >> > with a 0 > >> > >> Lots of numbers are labels that aren't meant to be calculated on. Item > >> number, part number, model number, serial number, order number. > >> Anything that needs to be distinguished and isn't worth naming. > >> > >> It's never a good idea to store such numbers as numerical types. > >> There's always a potential loss of information, be it the leading zero > >> or embedded '-' or multiple '.' characters. Unless the "number" is a > >> quantity, for compuational purposes it's text. > >> > >> --jkl > >> > >> _______________________________________________ > >> sqlite-users mailing list > >> sqlite-users@mailinglists.sqlite.org > >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >> > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
