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

This WebDNA talk-list message is from

2016

It keeps the original formatting. numero = 112952
interpreted = N
texte = 539Hi Alex,You reinforced my point I think...WebDNA has access to the best of both worlds. If you want strict=20datatypes, use SQL. If you want flexibility, use the WebDNA core=20database.DonovanOn 2016-09-01 07:05, Alex McCombie wrote:> There 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.>> 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=20> types> of searching for performance purposes (as ODBC slows over many> individual requests). I just think labeling the concept as=20> introducing> restrictions is disingenuous when I believe the concept has clearly> been identified as an optional parameter.>> Just my .02>> AJ>> On 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:=20>> leMODDATEdata=3D12/31/2015>>>> You explain that someone who would write "yesterday" would=20>> jeopardize the database integrity. We are in the case where a date can==20>> be freely written. So, imagine we get a date in European format,=20>> 31/12/2015, which is also the format adopted by 90% of the countries=20>> in the world (the format MDY is only US-based), or number written=20>> alternatively as 9,210.00 (US) o 9.210,00 (European). Let=E2=80=99s ta=lk about=20>> zip code, US based is a number with a "-" that would prevent this=20>> field to be treated as a number, english one could be C178AN, or the=20>> phone numbers with international +39 or +1, or inventories with text=20>> and numbers?>> Also, what about the "grouping fields", if you mix numbers with=20>> text? I also saw programs using dates in the format 12/31/16 (1916 or=20>> 2016?).>>>> We would have to think a way to specify each format in the database=20>> header, which would further restrict the use of the database by=20>> implying a *lot* of specific cases, while a simple test in the code=20>> could easily make all data searchable and make usable an heterogeneous==20>> database, a privilege that no other database system offers.>>>> I think it is little effort to add DeadlineType=3Ddate and that=20>> introducing restrictions in database format would just be introducing=20>> limits to creativity and flexibility.>>>>>> - chris>>>>>>>>> That being said, I completely disagree when it comes to storing and=20>>> retrieving information in a data structure. If i have a field in a=20>>> data structure (read: SQL data table or WebDNA database) that is for=20>>> storing dates, then allowing someone to store "yesterday" is=20>>> nonsensical and causes problems when I try to retrieve dates based on==20>>> a calculation. (i.e. leMODDATEdata=3D12/31/2015) Of course I should=20>>> write code that stops this data from being stored in the first place,==20>>> but as a last resort the database program itself should defend the=20>>> database to protect the integrity of the data stored in it. The side==20>>> effect, which almost outweighs the protection factor to be candid, is==20>>> that when retrieving info, if each field has a predefined data type,=20>>> the database already knows how to deal with searches so the=20>>> programmer doesn't have to reiterate for each search that this field=20>>> is a date, or a number, or whatever.>>>> --------------------------------------------------------->> 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 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:

539Hi Alex,You reinforced my point I think...WebDNA has access to the best of both worlds. If you want strict=20datatypes, use SQL. If you want flexibility, use the WebDNA core=20database.DonovanOn 2016-09-01 07:05, Alex McCombie wrote:> There 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.>> 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=20> types> of searching for performance purposes (as ODBC slows over many> individual requests). I just think labeling the concept as=20> introducing> restrictions is disingenuous when I believe the concept has clearly> been identified as an optional parameter.>> Just my .02>> AJ>> On 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:=20>> leMODDATEdata=3D12/31/2015>>>> You explain that someone who would write "yesterday" would=20>> jeopardize the database integrity. We are in the case where a date can==20>> be freely written. So, imagine we get a date in European format,=20>> 31/12/2015, which is also the format adopted by 90% of the countries=20>> in the world (the format MDY is only US-based), or number written=20>> alternatively as 9,210.00 (US) o 9.210,00 (European). Let=E2=80=99s ta=lk about=20>> zip code, US based is a number with a "-" that would prevent this=20>> field to be treated as a number, english one could be C178AN, or the=20>> phone numbers with international +39 or +1, or inventories with text=20>> and numbers?>> Also, what about the "grouping fields", if you mix numbers with=20>> text? I also saw programs using dates in the format 12/31/16 (1916 or=20>> 2016?).>>>> We would have to think a way to specify each format in the database=20>> header, which would further restrict the use of the database by=20>> implying a *lot* of specific cases, while a simple test in the code=20>> could easily make all data searchable and make usable an heterogeneous==20>> database, a privilege that no other database system offers.>>>> I think it is little effort to add DeadlineType=3Ddate and that=20>> introducing restrictions in Database format would just be introducing=20>> limits to creativity and flexibility.>>>>>> - chris>>>>>>>>> That being said, I completely disagree when it comes to storing and=20>>> retrieving information in a data structure. If i have a field in a=20>>> data structure (read: SQL data table or WebDNA database) that is for=20>>> storing dates, then allowing someone to store "yesterday" is=20>>> nonsensical and causes problems when I try to retrieve dates based on==20>>> a calculation. (i.e. leMODDATEdata=3D12/31/2015) Of course I should=20>>> write code that stops this data from being stored in the first place,==20>>> but as a last resort the database program itself should defend the=20>>> database to protect the integrity of the data stored in it. The side==20>>> effect, which almost outweighs the protection factor to be candid, is==20>>> that when retrieving info, if each field has a predefined data type,=20>>> the database already knows how to deal with searches so the=20>>> programmer doesn't have to reiterate for each search that this field=20>>> is a date, or a number, or whatever.>>>> --------------------------------------------------------->> 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 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. dbrooke@euca.us

DOWNLOAD WEBDNA NOW!

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

2016

Top Articles:

Related Readings: