To be clearer on the purpose:

There are many customers who use my application.

What I want to achieve is that they can ’share’ data. In order to do that, I 
really do need a UUID, because I intend to exchange the records (and related 
records) between their individual databases.
Obviously this will never work with LONGINT ids and foreign keys …

Another example is replication. My users, most of the time, are working 
client-server. But often, they need a part of the datafile as a local database 
on their laptop, so I need to replicate at least a part of 
the data into a stand-alone database. Then, if they add records to the local 
database, I want to replicate that new information back to the server database.

The only way this would be possible is to change all the LONGINT ids to UUID, 
and also the foreign keys ….

Regards,

Rudy Mortier
Two Way Communications bvba 



> On 24 Oct 2018, at 18:16, Chip Scheide via 4D_Tech <[email protected]> 
> wrote:
> 
> it is more of a situation of:
> - Do I **really** want to type a UUID to try to follow/check on  
> related records when something goes pear-shaped?
> - Do I want my admin(s) to have to type a UUID to try to chase related 
> records?
> - Do I want to have to work with UUIDs, other then knowing that they 
> exist and are inplace as requested/required?
> 
> 
> On Wed, 24 Oct 2018 10:59:48 -0500, Keith Culotta via 4D_Tech wrote:
>> RE: never use them to link between tables
>> 
>> Is using them to link between tables (establish 4D Relations, 
>> correct?) a hazardous practice? 
>> 
>> Thanks,
>> Keith - CDI
>> 
>>> On Oct 24, 2018, at 10:49 AM, Charles Miller via 4D_Tech 
>>> <[email protected]> wrote:
>>> 
>>> Rudy
>>> 
>>> For me this always choose UUID for primary key and never use them to link
>>> between tables. The overhead from space is not so great Andy I never want
>>> to type in uuid to find related records etc
>>> 
>>> Regards
>>> 
>>> Chuck
>>> 
>>> On Wed, Oct 24, 2018 at 10:52 AM Two Way Communications via 4D_Tech <
>>> [email protected]> wrote:
>>> 
>>>> I have an application with a big database file ( + 60 GB), with 128
>>>> tables. (4D v17)
>>>> 
>>>> All id fields and foreign keys are of type longint.
>>>> 
>>>> Now, for replication and sharing purposes, I would like to change the type
>>>> to UID.
>>>> 
>>>> The process seems quite cumbersome: to start, I need to remove the
>>>> ‘primary key’ flag from all the ID fields, then I need to add UID 
>>>> fields to
>>>> every table,
>>>> change the foreign keys as well, and use apply formula to make sure the
>>>> relations are intact. I am a bit worried that this will have a 
>>>> major impact
>>>> on the size of the data file.
>>>> 
>>>> Furthermore, I need to automate the whole process so the upgrade works
>>>> flawlessly at the customers site.
>>>> 
>>>> Has anyone ever done this?
>>>> Any tips?
>>>> 
>>>> Regards,
>>>> 
>>>> Rudy Mortier
>>>> Two Way Communications bvba
>>>> 
>>>> 
>> 
>> **********************************************************************
>> 4D Internet Users Group (4D iNUG)
>> Archive:  http://lists.4d.com/archives.html
>> Options: https://lists.4d.com/mailman/options/4d_tech
>> Unsub:  mailto:[email protected]
>> **********************************************************************
> ---------------
> Gas is for washing parts
> Alcohol is for drinkin'
> Nitromethane is for racing 
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[email protected]
> **********************************************************************

**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[email protected]
**********************************************************************

Reply via email to