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

This WebDNA talk-list message is from

2016

It keeps the original formatting. numero = 112950
interpreted = N
texte = 537There is nothing more restrictive about identifying field types at the =DB level when it's done via an optional file (similar to .hdr).It's one thing to say "we don't see this as a priority". it's quite =another to label it as a step backwards in flexibility and restrictions =when the feature request clearly identifies the optional implementation.=20=WebDNA is one of the only (if not the only) relational DB system that is =neither relational nor utilizes field definitions. There is no argument =that there in increased flexibility there. There is also often much more =work required to code in the safeguards that are standard fare for any =other system (that I know of). Additionally, I believe it's fair to say =that if pressed to remove that from other systems, the reply would cite =a loss of performance as the engine has to go through multiple routines =just to determine the proper way to handle the data. In essence, this =has the potential to actually speed up entire processing engine for DNA.I have no dog in this fight as we primarily use DNA as a code front end =for SQL. Our applications are in hundreds of school districts around the =state and serve thousands of students over millions of records. DNA =tables are solely used as RAM support for recursive types of searching =for performance purposes (as ODBC slows over many individual requests). =I just think labeling the concept as introducing restrictions is =disingenuous when I believe the concept has clearly been identified as =an optional parameter.Just my .02AJOn Sep 1, 2016, at 3:05 AM, christophe.billiottet@webdna.us wrote:> Hi Brian! I take back your example about the date in a database: =leMODDATEdata=3D12/31/2015>=20> 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=92s 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?).>=20> 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.>=20> 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.>=20>=20> - chris>=20>=20>=20>> 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>=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---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list .To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.usBug Reporting: support@webdna.us. Associated Messages, from the most recent to the oldest:

537There is nothing more restrictive about identifying field types at the =DB level when it's done via an optional file (similar to .hdr).It's one thing to say "we don't see this as a priority". it's quite =another to label it as a step backwards in flexibility and restrictions =when the feature request clearly identifies the optional implementation.=20=WebDNA is one of the only (if not the only) relational DB system that is =neither relational nor utilizes field definitions. There is no argument =that there in increased flexibility there. There is also often much more =work required to code in the safeguards that are standard fare for any =other system (that I know of). Additionally, I believe it's fair to say =that if pressed to remove that from other systems, the reply would cite =a loss of performance as the engine has to go through multiple routines =just to determine the proper way to handle the data. In essence, this =has the potential to actually speed up entire processing engine for DNA.I have no dog in this fight as we primarily use DNA as a code front end =for SQL. Our applications are in hundreds of school districts around the =state and serve thousands of students over millions of records. DNA =tables are solely used as RAM support for recursive types of searching =for performance purposes (as ODBC slows over many individual requests). =I just think labeling the concept as introducing restrictions is =disingenuous when I believe the concept has clearly been identified as =an optional parameter.Just my .02AJOn Sep 1, 2016, at 3:05 AM, christophe.billiottet@webdna.us wrote:> Hi Brian! I take back your example about the date in a database: =leMODDATEdata=3D12/31/2015>=20> 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=92s 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?).>=20> 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.>=20> 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.>=20>=20> - chris>=20>=20>=20>> 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>=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---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list .To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.usBug Reporting: support@webdna.us. Alex McCombie

DOWNLOAD WEBDNA NOW!

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

2016

Top Articles:

Related Readings: