Re^4: Reflections on the design of a pure-Moose web app...

http://www.perlmonks.org?node_id=752731

in reply to Re^3: Reflections on the design of a pure-Moose web app...
in thread Reflections on the design of a pure-Moose web app...

And why would one want to do that if not for having persistant objects?

Comment on Re^4: Reflections on the design of a pure-Moose web app...

Replies are listed 'Best First'.
Re^5: Reflections on the design of a pure-Moose web app... by stvn (Monsignor) on Mar 24, 2009 at 00:06 UTC
And why would one want to do that if not for having persistant objects? A relational database is just one way to store objects (and a very poor one at that). There is and have been better alternatives out there for many years, so the idea that you should ever have to go through that is just silly. If you choose to, or if your requirements dictate that you do, that is different, but you certainly don't have to use a RDBMS, it is just the most commonly chosen knee-jerk design decision out there. Languages like Smalltalk and LISP have had OODBs for a long time now and they are used very successfully in lots of real world mission critical apps. And even Java and .NET have a pretty decent and successful OODB out there as well. And Cocoa nib files are really just archived object graphs that the Cocoa framework unarchives when needed. Perl now has KiokuDB, a production-ready alternative to ORMs that does not suffer from impedance mismatch or any of the other annoying compromises that ORMs force you to make. My point is really that using a relational database as a dumb object store is neither good OOP or good database-ing. The right tool for the right job, which IMO is exactly what the OP did here. -stvn	[reply]
Re^6: Reflections on the design of a pure-Moose web app... by ruoso (Curate) on Mar 24, 2009 at 17:10 UTC
While KiokuDB is a neat project, most of the time, in my case, I take advantage of my relational database, not every operation is simply store and fetch, but very often I see myself doing most of the business logic in terms of the relational model. I'm not that all against KiokuDB, but it solves a different issue than DBIx::Class... In my case, I mostly can't allow myself using KiokuDB because I need my relational database to work as a relational database. daniel	[reply]
Re^7: Reflections on the design of a pure-Moose web app... by stvn (Monsignor) on Mar 26, 2009 at 21:12 UTC
Well, yes, if you need a relational DB, then you need something like DBIx::Class or Fey. But even this does not prevent you from also being able to use KiokuDB. I am currently working on a project where my objects are stored in KiokuDB using the KiokuDB::Backend::DBI backend and I am using Fey to access my non-object, relational data. The reason for this is that to model my objects in the RDBMS would result in an explosion of tables and a duplicated metadata which wouldn't really be useful to me because that data is only meaningful when it is in object form, not when it is sliced and diced into a bunch of relational tables. The rest of the app has relational data that makes little or no sense as objects. Just as with the above, putting this relational data into objects would result in an explosion of classes and duplicated metadata none of which would be useful for me, and would only make manipulating this data tedious and difficult. The right tool for the right job, that is all I am saying really. Too often people just assume "okay, I need a RDBMS" when they want to save data and don't really consider other forms of persistence. This is becoming an increasingly precarious assumption the more people use ORMs and model their business objects in pure OO rather then SQL. -stvn	[reply]
Re^8: Reflections on the design of a pure-Moose web app... by ruoso (Curate) on Mar 30, 2009 at 20:00 UTC
Re^9: Reflections on the design of a pure-Moose web app... by stvn (Monsignor) on Mar 30, 2009 at 23:49 UTC
Some notes below your chosen depth have not been shown here
Re^5: Reflections on the design of a pure-Moose web app... by autarch (Hermit) on Mar 24, 2009 at 04:44 UTC
A relational database is not an object store. Relational databases don't even exist, instead we have SQL. Anyway, a relational database is a data storage system. When writing code that uses said data, you may choose to fetch it and represent it in your program as objects. An ORM may help with this. Most ORMs are not object persistence thingies, and they don't expect you to treat the database as opaque blob storage which magically makes objects. At some level, you end up writing something kind of like a SQL query. If you truly want to store objects, and not store data in SQL tables, you should probably use an object database like Kioku.	[reply]

In Section Meditations