ORMs require a lot of investment, so do databases. There are contrarian opinions that say use neither. I'm not sure I could/would abandon SQL, definitely not for unstructured databases like Mongo or whatever else. I think that would be worse because you never really know what you are going to get from a query. Adding columns or whatever they're called without SQL seems like a real joy when some rows have it and some don't. I'm also not about to put the data in some long list of files, don't see that working out, trying to make an API correct without SQL. As the requirements change over time, yuck. BUT I think worth reading about anyways.
Uncle Bob's (Author of Code Complete) NODB
Seems like you would want to instantiate your objects with the data from the database (or wherever), so you can make those objects explode correctly if that data can't be reached. Probably already obvious. ORMs are great for the simple cases, but probably don't stay that way for long. Maybe other languages have great ORMs and I just haven't been exposed to them, but the top answer at SO for best Java ORM has "None" as preferred answer!! I mean, if your database accesses improve over time through the normal course of development, seems like you would lose a lot by not getting your hands dirty, trusting the ORM to get the best query for you. I've always grown frustrated trying to learn an ORM to do basic junk and given up. SQL only has 4 commands to learn. If you even count update since delete + insert.
Indexing a file by hand, very cool reading too. Takes the magic away from database indexes
Index a file with pack for fast access
Using indexing for faster lookup in large file