If the database is complex (or may become more so in future) then why not use Sql. It's just safer and more flexible.
GAE is great as a free way of dishing up views of single tables. With a few extra feeds here and there. Plus, whenever I have had a complex system and compromised (by denormalising) my data, I have invariably regretted it later. I mean here, more important corporate data rather than for example blogs and promotional websites. On May 16, 11:55 am, Marek Mollin <[email protected]> wrote: > Hello, > > As I have been more and more interested in GAE from app design > perspective. I lurked into the codebase for web2py's gae driver and it > seems to be mapping all the native futures I would like to have ( 'out > of the box without custom queries' ). However I am wondering about the > general experience. > > I know google has its up and downs with gae and I know the limitations > it imposes. However I am worried that if I layout my database in non- > rdbms fashion I have to design it with different paradigms in mind. > > Problem is what if I find google ineffective. My fears come from lack > of static system, since a lot of the stuff I will be doing within my > app will require file hosting. Have you done anything serious, > designed it to work with gae and then changed your mind and switched > to rdbms. > > I know I can change the driver, but its not that simple. Since I will > have data that's heavily denormalized and very redundant. Have you got > any studycase of migrating back and forth? > > Also how do you see the scalability of gae from large project > perspective. I am not talking dummy-apps, but have you for instance > developed an app that was designed to work with rdbms and switched to > google and noticed its running much faster... > > I am starting a big project, have web2py as my choice (at least now) > and after > readinghttp://www.carlosble.com/2010/11/goodbye-google-app-engine-gae/ > I am starting to rethink my choices. > Also another thing is lack of merge-join which I find would made life > easier(but I might be wrong? what's the story of implementing > those...?) > > Regards,
