ID Projects, ID Sheets & ID CSVs ( *** Discussion *** )

[icu]

Hi,
I think it was in relation to this former discussion in 2008 when we started with the origin set titles and converted them to chronological order.

Originally Posted by Al Gebra

I'm more familiar with the 'month/year' file naming convention of the early sets, and I don't know if the 'set' naming was or is still "official". All I can say is that
set01 ~ 1296a
set02 ~ 1296b
....
set99 ~ 1197i
set100 ~ 1197j,
next set is cc13a - the file naming convention still in use.

The sets starting with "5" are corresponding with magazines published 2002 and later by Silwa / ZBF after CCC stopped distributing magazines themselves.

Originally Posted by fannatastic

Yes, I think that set01 should be changed to 1296a, etc.

Is there a full list anywhere of sets ~ dates?

We also spoke about the U... sets that time, but sorry I do not remember where. I am not sure, but I think it was something with a source CSV ?

[BentBastard]

Originally Posted by icu

How shall we handle...
- sets without identified mags
- the 500s ( are also not separated from the .PS )

( I need a little time to change the .P to .PS )

Of course at the moment there is no .S Shoot info which to me should have preceeded .SA Shoot Actors. To complicate things, magazine stories, film stories, and official set images have and N to N relationship with shoots. For example: Stories such as "Teenage Photo Gallery", "Porno Album", "Color Climax Album" typically have images from multiple shoots. The loop "Sweet Memories" has footage from the magazine stories "Dice, Dicks And An Eager Cunt" and "Candle Delight". cc82x has images from Educating Tina and Maid In Heaven.

Up until know I had simply haddled these multiple shoot stories with comments, however I am currently in the process of restructuring my data. but I digress..

To answer your question a Shoot as I see it is a distinct entity from the magazines, films or image sets it appears in. Thus a .S and .SA listing is possible even though the magazine story is unknown. However this explanation is not entirely consistent with how fannatastic has set up .SA.

[12860491]

Might be an idea to put letters down the vertical axis of the ID contact sheet, i.e.:-

A
B
C
D
E

and put numbers along the horizontal axis :-


1 2 3 4 5 6 7

so models could be identified by grid square, for example, LATIN 3-D7 (meaning Latin sheet 3, fourth row down,seventh from the left).
Might make it a bit easier to keep track.
Could be used in addition to existing ident numbers and part names.


Using this system I think LATIN 2-D5 (Zoe 3) could be Michelle Monaghan.

[hos]

on which sheet thread are you referring to?

i guess, the problem with your idea is that this board doesn't offer the tools to create such a layout. you need something like tables for this issue.

[effCup]

Originally Posted by BentBastard

My 2 cents
ID: best porn name that we here at VEF prefer, if we are in agreement in the first place then this should rarely if ever change, obviously if it is changed then all other csv's linking to the model need to be updated. In many cases this will be the same as Professional Name: but need not be.
BB

Sorry for entering this thread so late in the piece, but:
When designing a database where the potential primary key is not immutable, one should instead create a surrogate primary key field, e.g. numeric.

Benefit: other tables linking to this one can then rely upon that primary key field. Allows all model names/ID to be altered as/when desired. Also allows different models with the same name, i.e. "Tina" or whatever is not a very good choice for primary key. NB, would need additional info. to distinguish this "Tina" from another of the same name, e.g. photo/nationality/filmography/whatever.

Cost: slightly greater complication to data structure, as would have something like:

modelKey [primary key, numeric, unique]
ID [agreed best name at VEF]
...

A normalised database, as opposed to a simple CSV, would have a related table of model names/aliases, and the ID field would be a foreign key pointing to whichever was the agreed best name:

Models table:
modelKey [primary key, numeric, unique]
ID [foreign key, corresp. nameKey selected for this model, perhaps null if undecided?]
Nationality
...

Names table:
nameKey [primary key, numeric, unique]
modelKey [foreign key to Models table]
name [string]

"Aliases" would be a lookup query/join based on Names with corresp. modelKey as their FK.

Sorry, my SQL is getting rust through lack of use.

Late edit:
A Names table would, however, only be useful if other data were being associated with those individual names/aliases.