It depends on what flexibility you want out of these lists of values.
If you think the list is likely to grow or you might want them in
different languages, or altered for different customers, then put them
all in a domain values table and map to them with ints. Then lift the
entire contents of that table across to the client.
That's the classic data warehousing approach to this problem and means
that the persistence tier is responsible for the model and mappings,
and the metadata and domain values are stored only once. It also
means that report writers can get at everything they need from the
database - if you have the requirement to report directly against your
data.
This is intellectualy the best approach, but it is also the most
complicated. In my experience, unless you have a firm set of
requirements for reporting it will introduce unnecessary complexity
and performance overhead to your persistence tier to code for that
theorietical eventuality, so you should only do it if your customer
has stated it as a necessity.
Alternatively, if they are genuinley just a few values which are
fixed, then I would still store int proxies for them in my data model,
but there's no need for an additional table, just use static text
variables in your client code so the values are consistents and
managed in a single place. Make an AS class called, say, "Constants"
and have something like this...
class Constants
{
public static var FREQUENCY_MONTHLY:int = 0;
public static var FREQUENCY_YEARLY:int = 1;
public static var FREQUENCY_MANUAL:int = 2;
public static var FREQUENCY_TEXT:ArrayCollection = new
ArrayCollection(["monthly", "yearly", "manual"])
}
then in your controls you can use these for binding (you'll get a
silly compiler warning) e.g.
<mx:ComboBox dataProvider={Constants.FREQUENCY_TEXT}
selectedIndex={my_value_object.frequency_field} id="myCombo" ... />
private function loadSelectionOntoValueObject():void
{
my_value_object.frequency_field = X.selectedIndex;
}
Both ways are valid, both have pros and cons, both store only an int
in your value object, it is just a question of where the management of
the list of values resides, client or database. You'll probably have
a good feel for which is best for your application.
hth
Simon
--- In [email protected], "Dan Tavelli" <[EMAIL PROTECTED]> wrote:
>
> This is sort of a database design question, but I am interested what
> the best practice is to store the following information and bind that
> data to controls in flex.
>
> Basically there is a form to show which reports a company is
> submitting, and if they are submitting at what frequency.
>
> In flex the UI would be:
> A checkbox that indicates whether they are submitting for that report.
> A combobox that indicates the frequency that report is being submitted.
>
> In MySQL:
> I was orginally thinking of using enum('true','false') for the
report_name
>
> and enum('monthly','yearly','manual') for report frequency.
>
> This didn't seem like it was the best solution, especially since there
> is more than one report and it didn't seem like a good design to have
> the same enum('montly','yearly'..) repeated for each report.
>
> Then I thought have one field with the report name with field type of
> INT. And if it was 0 that would indicate they were not submitting. 1
> would mean manually, 2 monthly..etc. Seems smarter but isn't very
> descriptive on the database side?
>
> I'm sure this is common scenario, what is the best practice for this?
>
> Dan
>
