Re: Here we go again...WebDNA - SQL- Clustering
This WebDNA talk-list message is from 2006
It keeps the original formatting.
numero = 66713
interpreted = N
texte = Alex McCombie wrote: > Lol the funny thing everyone is so passionately debating the WebDNA tables > VS. SQL like they are sworn enemies. > > Let me help (I hope) -- They work together. VERY WELL. > > I spent years on WebDNA. Besides Bob and Ken and a few others I would wager > that have been on here as long as anyone. Long long long time :-) > > Truth is I still use DNA flat files. And I also use the table tag to > temporarily store MSSQL data returns for recursive (RAM) searching. > > I use both. In the same page of code. And again, it works very very well :-) > > Why MSSQL? Well, there are lots of reasons. A few of them that come to mind > are > > Transactional Logging. There have been times when we needed to go to backups > and then rebuild all the data structure through time. Rare but it has > happened. > > Multiple points of entry and exit. I use it in an environment where there > are asp pages, php pages, Access Apps, and TPL pages and they all need to > manipulate the same data in REAL TIME. And no the data dumping, > import/exporting of data in bulk to be "semi-realtime" is not acceptable. > With DNA/MSSQL this is a snap. How much extra code is needed for this? Um, > none. > > True data warehousing as well as multiple front end servers hitting the same > data. Across the network or across the web it all doable. Again in real > time. > > > Why MSSQL instead of MySQL? Well mostly because its a MS shop. Gotta work > within the system. Frankly, if the tests all hold up it seems that the > syntax is identical if you hit MySQL with ODBC instead of the Native DNA > MySQL tags. Why is this so important? Well when your sitting there debugging > and need to hit the SQL server with your search in Query Analyzer its a lot > better when all you have to do is copy and paste your SQL tag which would > not work with the native tags (best I can tell). > > Huge data sets DO suffer from the undefined nature of WebDNA tables. Anyone > doing large text searches on the two can attest. It also suffers from no > field definition when doing date searches and math. > > Lets not forget about the join context instead of recursive searching! The > ability to group across multiple tables with doing recursive searching in a > FI loop will start making a HUGE difference on large data sets. > > > Don't get me wrong guys. I use WebDNA every single day for some pretty > in-depth tools (one rolling out to schools across NY soon). For the most > part now, we use DNA as the front end to MSSQL. We still do flat files > resident in DNA, and also will be doing MySQL (through ODBC soon). So I > don't see it as a either or. Integrating SQL tags was a critical maneuver on > the part of SMSI... If only it had come with marketing ;-) Alex, you, Ken, John H, John P, Brian and many others were at, if not near, "guru" status when I was most definately "diapers" status. Many of you helped me through the growing pains. I'm with you on just *about* every point on this. Businesses more and more want there core systems to work with their web systems. The new SQL tags help greatly with communication. It's very existance helps validate webdna to a larger audience. There have been a lot of changes with the product since I first got started. SMSI really has done a lot. I've noticed many transparent changes that have helped the performance of webdna... not to mention the obvious new tags. I remember the sluggish machines, and the sluggish simple searches. Those days are gone. What I know is that efficient code can go a long way on the current webdna versions. But, I'm with you... Use all the tools as needed. A question: "transactional logging"... how does this benefit over a good backup schematic? Donovan -- =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o DONOVAN D. BROOKE EUCA Design Center <- Web Development (specializing in eCommerce),-> <- Custom Paint, Labels, and Specialty Signage. -> <- Home and Business Embellishment/Fabrication, -> <- Glass Blowing, and Art Glass -> PH/FAX:> 1 (608) 835-2476 Web:> http://www.egg.bz | http://www.euca.us =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list
. To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
Alex McCombie wrote: > Lol the funny thing everyone is so passionately debating the WebDNA tables > VS. SQL like they are sworn enemies. > > Let me help (I hope) -- They work together. VERY WELL. > > I spent years on WebDNA. Besides Bob and Ken and a few others I would wager > that have been on here as long as anyone. Long long long time :-) > > Truth is I still use DNA flat files. And I also use the table tag to > temporarily store MSSQL data returns for recursive (RAM) searching. > > I use both. In the same page of code. And again, it works very very well :-) > > Why MSSQL? Well, there are lots of reasons. A few of them that come to mind > are > > Transactional Logging. There have been times when we needed to go to backups > and then rebuild all the data structure through time. Rare but it has > happened. > > Multiple points of entry and exit. I use it in an environment where there > are asp pages, php pages, Access Apps, and TPL pages and they all need to > manipulate the same data in REAL TIME. And no the data dumping, > import/exporting of data in bulk to be "semi-realtime" is not acceptable. > With DNA/MSSQL this is a snap. How much extra code is needed for this? Um, > none. > > True data warehousing as well as multiple front end servers hitting the same > data. Across the network or across the web it all doable. Again in real > time. > > > Why MSSQL instead of MySQL? Well mostly because its a MS shop. Gotta work > within the system. Frankly, if the tests all hold up it seems that the > syntax is identical if you hit MySQL with ODBC instead of the Native DNA > MySQL tags. Why is this so important? Well when your sitting there debugging > and need to hit the SQL server with your search in Query Analyzer its a lot > better when all you have to do is copy and paste your SQL tag which would > not work with the native tags (best I can tell). > > Huge data sets DO suffer from the undefined nature of WebDNA tables. Anyone > doing large text searches on the two can attest. It also suffers from no > field definition when doing date searches and math. > > Lets not forget about the join context instead of recursive searching! The > ability to group across multiple tables with doing recursive searching in a > FI loop will start making a HUGE difference on large data sets. > > > Don't get me wrong guys. I use WebDNA every single day for some pretty > in-depth tools (one rolling out to schools across NY soon). For the most > part now, we use DNA as the front end to MSSQL. We still do flat files > resident in DNA, and also will be doing MySQL (through ODBC soon). So I > don't see it as a either or. Integrating SQL tags was a critical maneuver on > the part of SMSI... If only it had come with marketing ;-) Alex, you, Ken, John H, John P, Brian and many others were at, if not near, "guru" status when I was most definately "diapers" status. Many of you helped me through the growing pains. I'm with you on just *about* every point on this. Businesses more and more want there core systems to work with their web systems. The new SQL tags help greatly with communication. It's very existance helps validate webdna to a larger audience. There have been a lot of changes with the product since I first got started. SMSI really has done a lot. I've noticed many transparent changes that have helped the performance of webdna... not to mention the obvious new tags. I remember the sluggish machines, and the sluggish simple searches. Those days are gone. What I know is that efficient code can go a long way on the current webdna versions. But, I'm with you... Use all the tools as needed. A question: "transactional logging"... how does this benefit over a good backup schematic? Donovan -- =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o DONOVAN D. BROOKE EUCA Design Center <- Web Development (specializing in eCommerce),-> <- Custom Paint, Labels, and Specialty Signage. -> <- Home and Business Embellishment/Fabrication, -> <- Glass Blowing, and Art Glass -> PH/FAX:> 1 (608) 835-2476 Web:> http://www.egg.bz | http://www.euca.us =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Donovan Brooke
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:
AutoCommit Preference? (1998)
[math] variable question (1997)
Separate SSL Server (1997)
WC2b12: Yes, Formulas.db is for real (1997)
checking for [ and ] in form fields ... (1997)
[subTotal] pricefield in another database It#180#s not working!? (1998)
Secure server question (1997)
Ampersand (1997)
Re:Authenticate (1998)
WebMerchant docs and testing (2000)
[isfolder] and [filename] (1997)
WebCat2 several catalogs? (1997)
WC 2.0 frames feature (1997)
WebDNA Solutions ... sorry! (1997)
Search/sort in URL Was: GuestBook example (1997)
[browsername] not working? (1997)
WebCatalog Plug-in for Webstar. (1997)
Mac v. NT (1998)
[shownext] help (2002)
[WebDNA] To be or not to be friendly (URLs) (2011)