psandler wrote:
Yes, absolutely. To quote myself from comments in my blog (http://psandler.wordpress.com/2009/12/10/database-standards-and-conventions/):
it may be thin, but underscores force the separation and easy reading of words within a name. In SQL Server (which is by far the database I use the most), names are not case sensitive, and casing is a much bigger factor if you use straight camel casing than if you use underscores. For example, “AssignmentTypeConfiguration” becoming “assignmenttypeconfiguration” vs. “assignment_type_configuration” becoming “Assignment_Type_Configuration”.
Again, I'm JUST getting started with 3.0, but as an observation: you always supported allow some pretty great flexibility for entity/field naming patterns using database first. It seems logical to support the exact reverse of that flexibility when doing model first.
That's a good point. We can't change the setting in the middle of a release, as that would cause problems when a project is opened in different builds, but we'll look into it in the next version.
You can 'cheat' if you want case sensitive behavior for naming btw . Open the file driver.config in the sqlserver driver folder and add:
<caseSensitiveElementNames>true</caseSensitiveElementNames>
to the <databaseDriver> element.
For example, I personally would not use "tbl" as a prefix for each table in my database, but what if that is my company's standard? In order to comply, I need to do database first or manually modify?
Good point indeed. We totally didn't think of this (as these prefixes/suffixes are actually not that great to have): it might be indeed someone is forced to use these prefixes/suffixes.
I think we'll add patterns for this in the next version.
I may end up doing database first anyway, not because of this limitation, but because it's the way I normally work. However I think a good long term feature would be to allow equal flexibility regardless of whether you are doing model or database first.
Yes, you're absolutely right.
psandler wrote:
Sorry for the many, many posts.
I would also request a feature of having some control over the primary key, foreign key, and unique constraint keys names that get generated in the DDL.
The problem is that they have to be unique and have to fit within the maximum length some databases state, so often within 30 or so characters. To avoid clashes with Fk's already in the db (which aren't imported) we generate a unique key based on a guid. This isn't ideal from a readability point of view, but it's otherwise a bit hard to produce unique constraint names for constraints and stay within length limits...