Yes, query batching too. The db-agnosticism is a less important point than the other stuff - they sell the app and would really prefer to have it but don't seem tremendously insistent on the fact.
Like I said, the reason they want to keep the database relatively the same is because the application is already in production as a VFP project. It already has thousands of deployments. They have already put in a significant amount of work toward creating a process to transform the existing db to sql server. They're open to tweaks, but it would be a enormous undertaking to make any sweeping changes to the structure. In any case, because of the dynamic nature of these grids (as in, the user can add columns) I'm not sure that I have a better structure to propose. I'm starting to think of the app as having two components - one where they design a database schema, and create updateable views, and then another component where they actually use these views... That's another thing that I would hope NH can help with given its UpdateSchema() abilities. On Thu, Mar 11, 2010 at 7:56 AM, Jason Meckley <[email protected]>wrote: > I can understand the clients resistance to change. however they did > hire you to update the system. Why are they willing to change the code > (logic), but not the data structure? It's not uncommon, many projects > still consider the database to be monolithic granite. if you have the > people skills, you may be able to craft a line of questioning which > gets to the root of the database design and why it cannot be altered. > from there you may be able to gain their confidence to alter the db > schema. > > some other thoughts. > *You mentioned making the code database agnostic. Is this really > necessary? I mean if this is proprietary software the chances of > database migration are very low. Porting the code to be database > agnostic provides very little ROI. > *Caching. I wouldn't worry too much about caching at this point, this > should be considered a last resort to improving preformance. most devs > jump to this option to boost preformance, but it's really not that > great. query optimization and batched sql statements will do much more > for performance than caching. > *Database schema. can the database generate views? if so you could > build views and map NH to the views and keep the underlying table > structure unchanged. This may allow you to get some of the benefits of > NH. you still need to workout the CUD actions, but it's a start. > > If you cannot get them to alter the database schema, I don't think NH > is the right choice for the solution. > > On Mar 11, 7:45 am, George Mauer <[email protected]> wrote: > > *Sigh* > > > > This is a foxpro to .NET conversion project and I just spent a full day > > meeting trying to see a way around these id-lists. Every time I bring it > up > > I get the response that "they have worked well for us in the past and > we're > > not paying to investigate something that is a radical departure". These > > lists are usually calculated in multi-step sql-statements and are one of > the > > more complicated bits of the application. They also do not want to change > > the table structure drastically because they have gone to a great deal of > > effort already figuring out how to transform their existing data to sql > > server. > > > > I think I mentioned this on here before but the application basically > > consists of grids which are very dynamic. The user can add and remove > > columns from these grids. When they add a column they map it to a > > corresponding "table" from the database. They can also add columns which > > are calculated off of other columns in the grid. Finally they can add > > "filters" which basically choose which rows of this mega-join are > visible. > > Certain columns they can edit manually and have the new value persisted > and > > the change reflected in other columns. Honestly, I find much of this to > be > > eerily similar to Excel. > > > > Like I said, I would like to use NH so that I can get the benefits of its > > concurrency control, transaction management, and caching. The idea for > now > > is to map each row of the grid as an "entity" (though this will probably > > evolve into a more complex strategy over time). Every time the user > > adds/removes/changes a column we change the underlying hbm mapping and > > re-build the session factory. I know perfectly well that this isn't > exactly > > how NH is meant to be used but I think its close enough and nhibernate is > > extensible enough that I can beat it into submission. If you guys know > of a > > better hammer for this job please let me know. > > > > As for custom tuplizers Fabio, I find only a handful of results for > googling > > it. Can you explain more what it does? > > > > On Wed, Mar 10, 2010 at 10:45 PM, Fabio Maulo <[email protected]> > wrote: > > > what this mean ? > > > "in order to get an entity that they can work with need to join across > as > > > many as 20 tables" > > > > > Have they <joined-subclass> with 20 classes ? > > > > > Which entity they are querying frequently (which level) ? > > > which is the weight of each entity in the hierarchy ? (how many > properties > > > and which type) > > > can they change the db ? > > > Have you a "simplified" actual mapping ? (simplified= without all > > > properties, only to have a better idea about what you are talking > about) > > > > > what I mean is that "override", probably, is not the solution; probably > the > > > solution is "change" the strategy they choosed. > > > > > btw, the answer to your question is: probably yes. > > > Using custom loaders, custom-sql for insert/update/delete and custom > > > tuplizers you can do a lot of things but before take this way we should > ask > > > ourself : > > > why the 3 strategies defined by ORM and the 4 strategies provided by NH > are > > > not enough in your case when are enough in thousand of applications ? > > > > > try to show us your cards. > > > > > 2010/3/10 George Mauer <[email protected]> > > > > >> I have some clients who in order to get an entity that they can work > > >> with need to join across as many as 20 tables. > > > > >> This is obviously a performance problem and they get around it > > >> currently by calculating what they call an id-table: > > > > >> table1_Id, table2_Id, table3_Id, etc. > > >> 11, 12, 13, ... > > >> 21, 22, 23, ... > > > > >> Where basically each row in this table represents a row in the final > > >> result set and each column represents the id of the row from the > > >> corresponding table that they need to join with. > > > > >> In other words they calculate this table, and only then do they > > >> retrieve the data by doing something like: > > > > >> SELECT table1.*, table2.*, table3.*, etc. > > >> FROM > > >> table1 > > >> INNER JOIN id_table ON table1.Id = id_table.table1_id > > >> INNER JOIN table2.Id = id_table.table2_id > > >> INNER JOIN table3.Id = id_table.table3_id > > >> ... > > > > >> I would like to introduce nhibernate for its concurrency, transaction, > > >> db-agnostic, and caching - is there a way to tell nhibernate to use > > >> this custom mapping strategy when mapping to an entity? > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "nhusers" group. > > >> To post to this group, send email to [email protected]. > > >> To unsubscribe from this group, send email to > > >> [email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > >> . > > >> For more options, visit this group at > > >>http://groups.google.com/group/nhusers?hl=en. > > > > > -- > > > Fabio Maulo > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "nhusers" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/nhusers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
