Use HiLo if possible, convince him this is the best way, or use guid.comthat creates less index fragmentation.
Tuna Toksöz Eternal sunshine of the open source mind. http://devlicio.us/blogs/tuna_toksoz http://tunatoksoz.com http://twitter.com/tehlike On Wed, May 27, 2009 at 12:01 AM, [email protected] < [email protected]> wrote: > > Unique identifiers are also considered the devil since they apparently > don't replicate (which I've never heard of) and they are slow. > guid.comb is extremely efficient but he wouldn't hear anymore about > it. > > The current insert sprocs do the following > INSERT INTO Table(ID, SomeColumn) WITH(XLOCK) VALUES( > ISNULL(MAX(ID), 0) + 1, > @SomeColumn > ) > > > On May 26, 4:57 pm, "[email protected]" > <[email protected]> wrote: > > Actually, I almost like Markus' idea. Thanks for that. I think I > > could add a default to the column in the DB. I'm not sure how this > > would handle criteria queries Expression.IsNull(child.Parent) etc. A > > lazy load of a many-to-one would still load up the placeholder record > > which is not ideal. > > > > The problem with the app I'm working on is that the DBA has a death > > grip on the database which is causing the dev group to be in a version > > lock because the database needs to update with every module/ > > application release due to everything being in stored procedures and > > views. We're unable to do parallel development on several modules/ > > apps at the same time that use the same database schema. The argument > > that views & sprocs allow for abstraction is untrue for the most part. > > > > On May 26, 4:50 pm, "[email protected]" > > > > <[email protected]> wrote: > > > 1) It would be nice to work with nullable datetimes in the code since > > > that is a "not set" scenario to object guys. I've already made the > > > user type that converts to/from the DB. It is easy and clean and > > > makes both parties happy. > > > 3) oh he hasn't accepted it yet. The argument being that it leaves > > > gaps in the IDs. If we have a bigint and the apps restart once a day, > > > it isn't going to leave alot of gaps in the IDs. I offered him unique > > > identifiers but we all know that didn't go anywhere. > > > 4) I've thought about adding a where map attribute to all the child > > > associates which I dislike and that doesn't solve the many-to-one > > > scenarios. I'm thinking I can override ManyToOneType & OneToManyType > > > to translate zero to null from the DB and NULL to 0 at the DB. To > > > prevent NH from thinking it is a new record, I'll probably have to set > > > unsaved-value = -1 or something weird like that. This is a stupid > > > requirement from the DBA imo! > > > > > On May 26, 3:45 pm, Fabio Maulo <[email protected]> wrote: > > > > > > 1) you don't need a custom user type (a DateTime had a value)2) you > don't > > > > need a custom user type (assign string.Empty to the property in the > Ctor) > > > > 3) Alleluia!!! a DBA accepting HighLow > > > > 4) here you really need to do something. Zero is a value and even if > you can > > > > use not-found="ignore" NH will try to get it before ignore (mean an > > > > additional SELECT)... in my mind no relation mean no value... but you > know > > > > I'm not a DBA or, at least, I'm an ORM-oriented guy. > > > > > > Try to convert ithttp://www.agiledata.org/essays/dbaSkills.html > > > > > > 2009/5/26 [email protected] <[email protected]> > > > > > > > I work with an extremely difficult SQL Server DBA that hates > anything/ > > > > > everything that is not a stored procedure. However, he's started > > > > > coming around and but has still placed the following constraints. > > > > > > > 1) Dates must be small datetime and NON-nullable. Nullable dates > are > > > > > equal to 1900/1/1. Easy enough to get around with a nh usertype > for > > > > > querying and persistence. > > > > > 2) Strings/VARCHAR must be non-nullable. Also very solvable via > empty > > > > > string nh user type. > > > > > 3) Idents are evil and will not be used. Easy to get around with > > > > > hilo. > > > > > 4) Now for the tough part which is where my question is. All > > > > > associations that are NULLABLE actually link to a "placeholder" > record > > > > > with ID 0. What would the community guys recommend? That I > override > > > > > the ManyToOne and OneToMany types to deal with this or do you have > a > > > > > better suggestion? > > > > > > > I have used NHibernate for several years now without ever so much > as a > > > > > blip of a problem. NHibernate is an ideal tool for the company I'm > > > > > with now assuming I can get around these DBA related issues. Has > > > > > anyone ever heard of some of these bizarre requirements and how did > > > > > you deal with them? > > > > > > -- > > > > 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] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
