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:
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:
[shell] (2003)
WCS Newbie question (1997)
Setting user and password (1999)
formula??? (2000)
Changing price for a SLU based on options (size, etc.) (1997)
Server crash (1997)
&max= (2003)
WebCatalog/Mac 2.1b2 New Features (1997)
Multiple prices (1997)
[isfile] ? (1997)
[protect] on NT? (1997)
PSC recommends what date format yr 2000??? (1997)
NetForms for mail, sorry (1998)
What might be the cause for a hicup (2000)
StandardConversions.db (1998)
return two fields w/ [lookup] (1998)
Looking up two prices in database? (1997)
multiple selected Checkboxes (1998)
nesting limits? (1998)
AD Error Msg (1997)