Αυτό που με ενοχλεί είναι το γεγονός ότι η ονομασία που δίνει με τον άσσο στο τέλος είναι τόσο μα τόσο...
Δυστυχως, αυτος ειναι ο τροπος που λειτουργει ο Entity Data Model Wizard και δεν προσφερει ιδιαιτερο ελεγχο στον τροπο δημιουργιας των entities.
Υπαρχει τροπος να διευρυνεις/επεκτεινεις τις λειτουργιες του wizard αλλα δεν γνωριζω κατα ποσο ειναι εφικτο να αλλαξεις το ονομα ενος entity μετα την δημιουργια του model. Ισως να αξιζει να ριξεις μια ματια σε αυτο (custom property after edmx is generated) :
http://msdn.microsoft.com/en-us/library/microsoft.data.entity.design.extensibility.imodelgenerationextension.onaftermodelgenerated.aspxΑπό την άλλη στο SSDL δεν έχει πρόβλημα τα έχει κανονικά στο σχήμα που είναι.
Στο storage model, το schema των πινακων ειναι απαραιτητο, εφοσον οι πινακες SchemaA.Table1 και SchemaB.Table1 ειναι διαφορετικοι data containers :
An EntitySet element in store schema definition language (SSDL) represents a table or view in the underlying database.
An EntityType element in SSDL represents a row in the table or view.
EntitySet (SSDL) attributes: Name, EntityType,
Schema, Table
EntityType (SSDL) attributes: Name
Στο conceptual model, ειναι το ονομα που διαχωριζει τις entities :
The EntitySet element in conceptual schema definition language is a logical container for instances of an entity type and instances of any type that is derived from that entity type.
The relationship between an entity type and an entity set is analogous to the relationship between a row and a table in a relational database.
Like a row, an entity type defines a set of related data, and, like a table, an entity set contains instances of that definition.
An entity set provides a construct for grouping entity type instances so that they can be mapped to related data structures in a data source.
EntitySet (CSDL) attributes: Name, EntityType
EntityType (CSDL) attributes: Name, BaseType, Abstract, OpenType
Ο model designer (αλλα και ο κωδικας της εφαρμογης) "χρησιμοποιουν" το conceptual model, στο οποιο ΔΕΝ υπαρχει η εννοια του Schema (οπως χρησιμοποιειται στις databases).
...δεν μιλάμε για μικρή βάση όσον αφορά τον αριθμό των πινάκων, είναι πάρα πολλοί...
Ισως θα πρεπει να χρησιμοποιησεις πολλαπλα models (συν των αλλων, ενα απο τα κριτηρια για διαφορετικα models θα μπορουσε να ειναι και το schema των πινακων (με καποια επιφυλαξη)):
http://thedatafarm.com/blog/data-access/creating-models-from-databases-with-billions-of-tables/
Επίσης τρέμω στην σκέψη ότι ίσως χρειαστεί να γίνει μια αλλαγή στην βάση και θα πρέπει να γίνει update το model.
http://stackoverflow.com/questions/3273120/entity-framework-v4-preventing-storage-model-overwrites-by-update-model-wizard
ξέρω ότι το τραβάω στα όρια του, αλλά δεν μπορώ να δεχθώ με τίποτα όμως τον SQL Server σαν κουβά δεδομένων
I know exactly what you mean, αλλα πολλοι application developers (με 'η χωρις το entity framework) καπως ετσι παρεξηγουν/αντιλαμβανονται τους database servers (ως εναν κουβα) ιδιως οταν μπορουν να αρχισουν να γραφουν κωδικα χωρις να απαιτειται καν η φυσικη παρουσια βασης (EF4, code first development)
Το EF is not my cup of tea και οι καποιες γνωσεις/πληροφοριες σχετικα με το framework δοθηκαν κυριως απο συναδελφους σε συζητησεις κ απο 2-3 ενδιαφερουσες παρουσιασεις (monthly architecs knowledge sharing) στα πλαισια της δουλειας.
Οπως και να 'χει, καλη επιτυχια με το Project.
--HTH--