ORM and beyond ..

My recent work involved writing something that is resembling more and more like a ORM implementation , like a deformed and abandoned sibling to Hibernate ;) . This in an environment where bitching about everything that's wrong with ORM makes for a good intellectual conversation and where NoSql is the topless bar that we as teenagers have sneaked into , tantalizing but not sure what to make of it .
So following is a list of issues that i have hit while working here , these are not exactly eureka stuff , these are common stuff that have been solved many times over . With the disclaimer that i am a novice in this i still document them as a note to myself as go forth and look into the wilderness for answers to some of them , will much appreciate if some of the readers can point me to the direction of solutions or more questions.

1. When i am writing a ORM based persistance layer it should be enuf , after the major models have been identified , to just have 2 methods for the models i.e save(Model mdl) and get(). is tat so ??

2. What is the granularity of the domain model ?? Given any domain it is always possible to have one super-grand-model that holds everything else like a company class that has departments that has ..... so any update on any employee on any department would still result in a save(Company cmp) . This is my understanding and my feeling is something is embarassingly wrong here , so wat is wrong ??
Now to spice things up a little bit more let us throw document-oriented dbs in how does all these things tie up. Documents to model ties up nicely with wonderful things like json , Jackson etc, but when things are large like u have a zillion departments and u have to update home address of 9999th user in 78976th dept u still have to deserialize the entire elephant (company in this example) and then iterate and change and persist .
Something is obviously very wrong here and i suspect the traditional object oriented view of data is the culprit , can anybody enlighten ??

3. When modelling a relationship what factors determine navigability , i mean as normal java guy it is most convienient to be able travel to and fro from any point in hierarchy . But should we enforce some discipline there ??

4. Getting back to the example scenario of point 2 above , say there is a composition we want to model like a Department having n people associated with it and say one among the n is a departmentHead a fact that we know from his role (role is also used by our security system). But the technical pain here is whenever i read a department object with thousands of people in it , and i want to know who the head is i have to iterate through the list of 1000 to get to it. There is an urge to keep a reference of this guy directly under the Department class that saves a lot of iteration but that is duplication of information also , but still this solution can be used if this is something we do at the programming layer and change db design for it . Any thoughts.

5. In enterprise apps space where the demands scalability is limited does the noSql,commodity sever camp bring any value or they are still going to stay old school for some time.

To be continued..