Skip to Content

Changes for page Best Practices-Model

Last modified by Theodore Petrosky on 2014/02/20 18:51
From version 27.1
edited by arroz
on 2007/12/20 11:40
Change comment: There is no comment for this version
To version 29.1
edited by arroz
on 2007/12/20 11:52
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -17,13 +17,18 @@
17 17  There are two main reasons for this:
18 18  
19 19  * There are some things EOF simply can't guess. If you have a String, you need to decide how much space you want to use on the database for it. If you know the String will contain a color, like "Red" or "Yellow", something like a varchar 50 should be enough. On the other end, if the String will be used to store a full name of a user, you probably want to make it a varchar 1000 or so (European names can be very long!). Of course, most databases allow you to use unlimited text data types, but that has serious implications in the database speed. So, it's up to you.
20 -
21 21  * You may be constrained to existing data types. If you are building an WO application on top of an existing database with millions of records, you cannot choose the data types you want to use - you must use the existing ones used by the database. So, you have to tell EOF what types are those, so that it can read and write information to your existing database.
22 22  
23 23  If you already tried to create a model, by following [[Janine's tutorial>>http://wotutorial.furfly.com/downloads.html]] or so, you know how flexible it can be - and how tedious it is. It shouldn't be needed to choose, for every integer in your model, the data type for it. Or the data type for every primary key. Or the data type for every string. Worse, if you decide you want to use higher precision floats on all your application, or if you want to increase the size of some of the strings you use in your data model, you should be able to change that information on only one place. After all, duplicating code is bad, right? So why can't you do it?
24 24  
25 -Well, you can! That's what prototypes are for.
24 +Well, you can! That's what prototypes are for. A prototype allows you to:
26 26  
26 +* Define the data type mappings between your model and the database internal types all in one place.
27 +* Use the same mappings for all your applications and frameworks.
28 +* Change information on one place, everything gets updated.
29 +* Create slight variations to the defined mapping in a given attribute.
30 +* Change DB easily without touching your models.
31 +
27 27  eogenerator
28 28  
29 29  to-many relationships