Re: well sort of - database design

This WebDNA talk-list message is from

2003


It keeps the original formatting.
numero = 50341
interpreted = N
texte = On 5/13/03 9:34 AM, Kenneth Grome wrote:> Hi Alex, > > If you're shooting for the ideal situation, I would say that the best > solution is an SQL database. If you can think of ways to not search > it too often, that will probably make things run faster. Not to kill this thread but I have often thought that if SMSI wanted to push the product to the next level they ought to consider the ability for the admin to identify tables that are searched 'sql style' from a file in addition to the ability to have most of the tables run from RAM.Yes, I know all the arguments regarding the speed of RAM DBs. Don't get me wrong, RAM data is blazingly fast and one of the main benefits of WebDNA... But if we could also utilize the same search code to dig through file based tables (especially those of extreme size) then we would not have to go into other systems once we reached that 'wall'. Its great that we can hook into SQL (mostly) but it would be much much nicer if it was self contained.It seems that, understanding the issues of performance, most of the codeset in WebCat would remain the same, with the file handling routines needing the additional work.I would LOVE to know that contained within WebDNA, and without the need to hook into external systems, there was NO WALL regarding RAM and file size, with only issues of performance for us to deal with, WHEN AND IF, we decided the need to go that route was needed.Anyway, for now it looks like I will have to be making some tough choices on this, because by all my estimates the data sets on this project are going to be significant and with the issue of load balancing to boot we may be forced to go elsewhere... Bummer.Thanks for the perspectives though. AlexAlex J McCombie New World Media Chief Information Officer Drawer 607 888/892.6379 Fair Haven, NY 13064 Alex@NewWorldMedia.com http://OurClients.comInterface Designer WebDNA Programmer Database Designer------------------------------------------------------------- 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:

    
  1. Re: well sort of - database design (Alex McCombie 2003)
  2. Re: well sort of - database design (Kenneth Grome 2003)
  3. Re: well sort of - database design (Alex McCombie 2003)
  4. Re: well sort of - database design (Kenneth Grome 2003)
  5. Re: well sort of - database design (Andrew Simpson 2003)
  6. Re: well sort of - database design (Alex McCombie 2003)
  7. Re: well sort of - database design (Andrew Simpson 2003)
  8. OT: well sort of - database design (Alex McCombie 2003)
On 5/13/03 9:34 AM, Kenneth Grome wrote:> Hi Alex, > > If you're shooting for the ideal situation, I would say that the best > solution is an SQL database. If you can think of ways to not search > it too often, that will probably make things run faster. Not to kill this thread but I have often thought that if SMSI wanted to push the product to the next level they ought to consider the ability for the admin to identify tables that are searched 'sql style' from a file in addition to the ability to have most of the tables run from RAM.Yes, I know all the arguments regarding the speed of RAM DBs. Don't get me wrong, RAM data is blazingly fast and one of the main benefits of WebDNA... But if we could also utilize the same search code to dig through file based tables (especially those of extreme size) then we would not have to go into other systems once we reached that 'wall'. Its great that we can hook into SQL (mostly) but it would be much much nicer if it was self contained.It seems that, understanding the issues of performance, most of the codeset in WebCat would remain the same, with the file handling routines needing the additional work.I would LOVE to know that contained within WebDNA, and without the need to hook into external systems, there was NO WALL regarding RAM and file size, with only issues of performance for us to deal with, WHEN AND IF, we decided the need to go that route was needed.Anyway, for now it looks like I will have to be making some tough choices on this, because by all my estimates the data sets on this project are going to be significant and with the issue of load balancing to boot we may be forced to go elsewhere... Bummer.Thanks for the perspectives though. AlexAlex J McCombie New World Media Chief Information Officer Drawer 607 888/892.6379 Fair Haven, NY 13064 Alex@NewWorldMedia.com http://OurClients.comInterface Designer WebDNA Programmer Database Designer------------------------------------------------------------- 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/ Alex McCombie

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:

unable to launch acgi in WebCat (1997) Search design (1997) WebCatb15 Mac CGI -- [purchase] (1997) Secure server question (1997) Adding headers to email (1997) Hosting (2000) t or f (1997) unsubscribe (2000) WCS Newbie question (1997) Problems with WebCat (2000) Help! WebCat2 bug (1997) HomePage Caution (1997) shipcost (1997) Re:no [search] with NT (1997) Join us at MacWorld -- in the booth and after the show!!! (1999) carriage returns in data (1997) How to Display text in empty fields (1997) [BULK] [WebDNA] Multiple e-mail sending (2011) WebCat2b14MacPlugIn - [include] doesn't hide the search string (1997) Header values are not accepted (1998)