Ya'll are correct. Mayhap we'll call them hashes. Or HUIDs. That way we know what we're talkin' about. :D
From: Eric Schultz [mailto:wwaha...@gmail.com] Sent: Thursday, August 12, 2010 5:39 PM To: Trevor Dennis Cc: Garrett Serack; coapp-developers@lists.launchpad.net Subject: Re: [Coapp-developers] Questions, Questions, Questions I don't think we should call this a GUID if you're not using the official definition of a GUID/UUID from RFC 4122. If I see GUID in documentation, I'm going to assume I can call a normal GUID creation function to create one. I think you bring up a good point Trevor. I'm a bit of a stickler on the wording myself. The main reason we used the word GUID is that MSI has a column format for GUIDs. Maybe we could use a different word or phrase like 'hashed GUID' or 'HUID'? It would imply it looks and acts like a GUID but it can't be created using GUID functions. It's not good practice to prefix table and columns and tables with things like 'tbl' or 'fk'. Save the FK_ for the name of the constraint and not the name of the column. If you're trying to relate columns in different tables, then simply give them a consistent name. Don't give one table 'ID' and the second table 'PACKAGE_ID'. Simply use 'PACKAGE_ID' for both. Their relationship becomes obvious. That suggestion sounds fine with me. I don't see a reason to use prefixed columns unless someone else does. Eric On Thu, Aug 12, 2010 at 7:18 PM, Trevor Dennis <tre...@dennis-it.com<mailto:tre...@dennis-it.com>> wrote: Hi, Here's some suggestions from what I've learned from years of database work and many articles from SQL development forums. >> In the CO_PACKAGE table, there is an id field. What type is this field >> supposed to be and where does it come from? (autogen by mkPackage, autogen >> by previous part of CoApp toolchain or set by the developer) >> Are CoApp package IDs globally unique? If I say I want package with ID 1, I >> can be safe knowing no other package from any repo will have that ID? Are >> these the IDs you had mentioned should be generated in a consistent manner, >> say with MD5 hashes of name, version, architecture and I assume the >> developer's public key? I think ID was intended to be a GUID generated as an MD5 of the {name + arch + version + publickeytoken}. Let's go with that assumption right now. I don't think we should call this a GUID if you're not using the official definition of a GUID/UUID from RFC 4122. If I see GUID in documentation, I'm going to assume I can call a normal GUID creation function to create one. If you're going to create a specific hash for an ID, then refer to it as a hash. >> - Do CO_ROLE, CO_TAG and CO_BINDING_POLICY actually get their >> FK_package_id's from CO_PACKAGE_PROPERTIES? That's what the diagram shows >> but it doesn't really make sense to me why that'd be. :) The FK_package_id is the foreign key for the package id... which is simply the ID field in the CO_PACKAGE table. FK_role_id is just the ID of the CO_ROLE table. It's not good practice to prefix table and columns and tables with things like 'tbl' or 'fk'. Save the FK_ for the name of the constraint and not the name of the column. If you're trying to relate columns in different tables, then simply give them a consistent name. Don't give one table 'ID' and the second table 'PACKAGE_ID'. Simply use 'PACKAGE_ID' for both. Their relationship becomes obvious. Also, there is no problem prefixing tables with 'CO' for CoApp since it provides a semi-namespace. But, don't prefix all the columns the same way. Simply name them for what they are (while avoiding SQL keywords). I haven't seen the original message or source though so if you weren't doing this, then ignore me. Enjoy your Thursday morning :) Eric -- Trevor Dennis
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
