Re: [WebDNA] Wishlist: ignore whitespace in database changes

This WebDNA talk-list message is from

2016


It keeps the original formatting.
numero = 112947
interpreted = N
texte = 534 Hi Brian! I take back your example about the date in a database: = leMODDATEdata=3D12/31/2015 You explain that someone who would write "yesterday" would jeopardize = the database integrity. We are in the case where a date can be freely = written. So, imagine we get a date in European format, 31/12/2015, which = is also the format adopted by 90% of the countries in the world (the = format MDY is only US-based), or number written alternatively as = 9,210.00 (US) o 9.210,00 (European). Let=E2=80=99s talk about zip code, = US based is a number with a "-" that would prevent this field to be = treated as a number, english one could be C178AN, or the phone numbers = with international +39 or +1, or inventories with text and numbers? Also, what about the "grouping fields", if you mix numbers with text? I = also saw programs using dates in the format 12/31/16 (1916 or 2016?). We would have to think a way to specify each format in the database = header, which would further restrict the use of the database by implying = a *lot* of specific cases, while a simple test in the code could easily = make all data searchable and make usable an heterogeneous database, a = privilege that no other database system offers. I think it is little effort to add DeadlineType=3Ddate and that = introducing restrictions in database format would just be introducing = limits to creativity and flexibility. - chris > That being said, I completely disagree when it comes to storing and = retrieving information in a data structure. If i have a field in a data = structure (read: SQL data table or WebDNA database) that is for storing = dates, then allowing someone to store "yesterday" is nonsensical and = causes problems when I try to retrieve dates based on a calculation. = (i.e. leMODDATEdata=3D12/31/2015) Of course I should write code that = stops this data from being stored in the first place, but as a last = resort the database program itself should defend the database to protect = the integrity of the data stored in it. The side effect, which almost = outweighs the protection factor to be candid, is that when retrieving = info, if each field has a predefined data type, the database already = knows how to deal with searches so the programmer doesn't have to = reiterate for each search that this field is a date, or a number, or = whatever.=20 --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us . Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] Wishlist: ignore whitespace in database changes (Stuart Tremain 2016)
  2. Re: [WebDNA] Wishlist: ignore whitespace in database changes (Patrick McCormick 2016)
  3. Was: [WebDNA] Wishlist: ignore whitespace in database changes - Now: WebDNA Data Model (dbrooke@euca.us 2016)
  4. [BULK] Re: [WebDNA] Wishlist: ignore whitespace in database changes (Alex McCombie 2016)
  5. Was: [WebDNA] Wishlist: ignore whitespace in database changes - Now: WebDNA Data Model (dbrooke@euca.us 2016)
  6. Re: [WebDNA] Wishlist: ignore whitespace in database changes (christophe.billiottet@webdna.us 2016)
  7. Re: [WebDNA] Wishlist: ignore whitespace in database changes (Stuart Tremain 2016)
  8. Re: [WebDNA] Wishlist: ignore whitespace in database changes (Brian Burton 2016)
  9. Re: [WebDNA] Wishlist: ignore whitespace in database changes (Kenneth Grome 2016)
  10. Re: [WebDNA] Wishlist: ignore whitespace in database changes (christophe.billiottet@webdna.us 2016)
  11. Re: [WebDNA] Wishlist: ignore whitespace in database changes (Brian Burton 2016)
  12. Re: [WebDNA] Wishlist: ignore whitespace in database changes (dbrooke@euca.us 2016)
  13. [WebDNA] Wishlist: ignore whitespace in database changes (Brian Burton 2016)
534 Hi Brian! I take back your example about the date in a database: = leMODDATEdata=3D12/31/2015 You explain that someone who would write "yesterday" would jeopardize = the database integrity. We are in the case where a date can be freely = written. So, imagine we get a date in European format, 31/12/2015, which = is also the format adopted by 90% of the countries in the world (the = format MDY is only US-based), or number written alternatively as = 9,210.00 (US) o 9.210,00 (European). Let=E2=80=99s talk about zip code, = US based is a number with a "-" that would prevent this field to be = treated as a number, english one could be C178AN, or the phone numbers = with international +39 or +1, or inventories with text and numbers? Also, what about the "grouping fields", if you mix numbers with text? I = also saw programs using dates in the format 12/31/16 (1916 or 2016?). We would have to think a way to specify each format in the database = header, which would further restrict the use of the database by implying = a *lot* of specific cases, while a simple test in the code could easily = make all data searchable and make usable an heterogeneous database, a = privilege that no other database system offers. I think it is little effort to add DeadlineType=3Ddate and that = introducing restrictions in Database format would just be introducing = limits to creativity and flexibility. - chris > That being said, I completely disagree when it comes to storing and = retrieving information in a data structure. If i have a field in a data = structure (read: SQL data table or WebDNA database) that is for storing = dates, then allowing someone to store "yesterday" is nonsensical and = causes problems when I try to retrieve dates based on a calculation. = (i.e. leMODDATEdata=3D12/31/2015) Of course I should write code that = stops this data from being stored in the first place, but as a last = resort the database program itself should defend the database to protect = the integrity of the data stored in it. The side effect, which almost = outweighs the protection factor to be candid, is that when retrieving = info, if each field has a predefined data type, the database already = knows how to deal with searches so the programmer doesn't have to = reiterate for each search that this field is a date, or a number, or = whatever.=20 --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us . christophe.billiottet@webdna.us

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

RE: [WebDNA] Anyone else getting double emails from this list (2009) using showpage and showcart commands (1996) [WebDNA] Store module/site (2012) Searching for the end (1998) DomainList (2005) WebCat2b13 Command Reference Doc error (1997) TeaRoom Order fields email account remain empty even though thewy are filled. (1997) General Purpose Database utility ????? (2003) searchable list archive (1997) Webcat2, WebCommerce, Mod 10 etc. (1997) Problem with summary on date / inconsequent webcat behaviour (1998) [isfile] ? (1997) WebCat2b15MacPlugin - [protect] (1997) WebCat2b13MacPlugIn - [showif][search][/showif] (1997) Server Error Question [bug?] (2004) WebCat2 - Getting to the browser's username/password data (1997) Sticky .inc file! (2008) any suggestions for creating a multi-lingual site? (1999) Displaying photo attached to first record (1997) REPOST: The old multiple selection bit (2000)