[flexcoders] [Flex Data Services] Managed associations / DB abstraction ?

2006-08-16 Thread Thomas Rühl

Hello flexcoders,

following the «Managed Associations» approach, I just encountered a 
question.

Please assume this:
I have a set of entities created in my database, i.e. Employee and 
Company - to stick with the examples. In contradiction to the examples, 
assume that they relate in a n-m manner, meaning one company can have 
any number employees and one employee can have any number of companies. 
For that, to come up with a good database layout, I'd need to design a 
corresponding relation in the database - «Employee», «Company» and 
«EmployeeHasCompany» (the ladder one is the n-m relation - it holds 
foreign keys to each, employee and company).

Let's say all of that is set so far and the application's requirements 
demand the database level cohesion of data and for that, require the 
table structure to be like I pointed out.

Now here's some random thoughts... How do I model that for use with the 
Flex Data Services? I know, there's some destination properties 
(one-to-one, one-to-many, ...) on which basis FDS manages data supply. 
Isn't that situation not only redundant but also risky to use? I'm 
thinking of transactions, date consistency and else... And how do I 
update the EmployeeHasCompany relation with new data? Is it like I need 
to trust FDS to do the right things? I'm afraid of losing control here.

So all in all, I think, my question is how to transfer the database 
model accordingly to the FDS confuguration? Or maybe I'm just off the 
track here.

Cheers, Thomas


  
  Thomas Rühl
  Design, Programming & Concepts
  
  akitogo OHG
  Hanauer Landstrasse 188
  60314 Frankfurt
  
  Telefon +49 (0) 69 800 69 445
  Fax +49 (0) 69 800 69 449
  Mobil   +49 (0) 179 750 75 87
  E-Mail  [EMAIL PROTECTED]
  Web http://www.akitogo.com
  





--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 




RE: [flexcoders] [Flex Data Services] Managed associations / DB abstraction ?

2006-08-16 Thread Matt Chotin












Hi Thomas,

 

What FDS is going to use those
relationships for is ensuring that it keeps track of items on the client for
consistency and attempts to avoid having the same item twice (everything is
kept in sync).  In this case you would define the relationship in the metadata
as many-to-many I believe.  It will be up to your assembler to actually update the
database tables, so you are in complete control of that aspect.  FDS does not
do any database manipulation, it simply sends you change objects which indicate
the updates the client wants to make.  If the client makes a mistake, your
assembler can take care of notifying the app of an error.

 

HTH,

Matt

 









From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Thomas Rühl
Sent: Wednesday, August 16, 2006
7:03 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] [Flex Data
Services] Managed associations / DB abstraction ?



 








Hello flexcoders,

following the «Managed Associations» approach, I just encountered a 
question.

Please assume this:
I have a set of entities created in my database, i.e. Employee and 
Company - to stick with the examples. In contradiction to the examples, 
assume that they relate in a n-m manner, meaning one company can have 
any number employees and one employee can have any number of companies. 
For that, to come up with a good database layout, I'd need to design a 
corresponding relation in the database - «Employee», «Company» and 
«EmployeeHasCompany» (the ladder one is the n-m relation - it holds 
foreign keys to each, employee and company).

Let's say all of that is set so far and the application's requirements 
demand the database level cohesion of data and for that, require the 
table structure to be like I pointed out.

Now here's some random thoughts... How do I model that for use with the 
Flex Data Services? I know, there's some destination properties 
(one-to-one, one-to-many, ...) on which basis FDS manages data supply. 
Isn't that situation not only redundant but also risky to use? I'm 
thinking of transactions, date consistency and else... And how do I 
update the EmployeeHasCompany relation with new data? Is it like I need 
to trust FDS to do the right things? I'm afraid of losing control here.

So all in all, I think, my question is how to transfer the database 
model accordingly to the FDS confuguration? Or maybe I'm just off the 
track here.

Cheers, Thomas



Thomas Rühl
Design, Programming & Concepts

akitogo OHG
Hanauer Landstrasse 188
60314 Frankfurt

Telefon +49 (0) 69 800 69 445
Fax +49 (0) 69 800 69 449
Mobil +49 (0) 179 750 75 87
E-Mail thomas.ruehl@akitogo.com
Web http://www.akitogo.com








__._,_.___





--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com








   






  
  
SPONSORED LINKS
  
  
  

Web site design development
  
  
Computer software development
  
  
Software design and development
  
  


Macromedia flex
  
  
Software development best practice
  

   
  







  
  
  YAHOO! GROUPS LINKS



   Visit your group "flexcoders" on the web. 
   To unsubscribe from this group, send an email to: [EMAIL PROTECTED] 
   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



  






__,_._,___