My Database
PreambleArtists historically have a bad reputation for clutter, which is based on a stereotype that in my case is utterly correct. My desk is piled high with things that I find interesting. Right now, on my desk, I have:
The monocle puzzles me a bit. Did I intend to alter it so it would fit me better? Am I secretly Lord Peter Whimsy? No matter. This is a snapshot of /some/ of the clutter. I like it, and it says that this desk is mine, and nobody in their right minds would disagree. However, it is not good enough to be cluttered and inefficient in some things. My knives are sharp, and my craft tools are in their boxes. My philosophy texts are all neatly filed. My reference photos are nicely backed up, thank you. These things, I take seriously, and another thing that is about to join them is my filing of art. I need a database. I have written one before, when I was actually paid to do that sort of thing, and I know how to do it, but I do not know what this needs to do – only that if I do not do it, I will get into a horrible horrible muddle. I need to write it out to get it clear, so that I can draw it, and then I can build it. So here it is, for my use and anyone else’s curiosity. The BuildI can have several items with the same image. IMAGE is a high level table that will have a queryable family that will tell me what the original is like, if there are any prints, if the edition is limited, and if there are any other sale streams, like DeviantArt postcards or mouse-mats with mice on. To me, this says that I need something with lots of small children so that if necessary I can go back and add tables and they will not interfere with current data. I know that altering the build later may not be best practice, but I do not know right now how to build a table for a screen print or a dry-point or a sculpture. I do know how to make them for other things, and I need this functional now. Hence, little modular tables that just slot in. An IMAGE will generally but not always have an ORIGINAL. Other things it might have are LE PRINTs, OE PRINTs (Open Edition), MERCHANDISE STREAMs of different sorts. An IMAGE is in itself not a work of art, but the particular shape of pigment or medium I have decided to use. Pleasingly, it will have a picture. I like pictures. LE PRINTs need a size for the print run. This should be stored off the table for the LE itself, and so in fact an IMAGE will have an LE RUN and then the LE RUN will have the LE PRINT. LE RUN will have the size of the edition and the price, and the data on paper, pigment, printing method, or screens and inks used, or lino type. This looks very much like it will have sub-tables for each style or medium I might use. It will also confirm if necessary that any printing masters have been cancelled after the run is over. LE PRINT will have Number, Buyer, and Location, as well as data on the sales process. Y/N boxes for Printed:Signed:Sent:Received:Invoiced:Paid, which are largely independent of each other. The OE tree will follow the same pattern, but there may be more than one OE RUN, as I could print in different sizes, in different media, etc. I need to keep track of those things so that I can potentially offer to limit the edition, or tell clients what is out in the world already. MERCHANDISE STREAMs are awkward. They are essentially OE Runs on websites like Cafepress or Deviant Art. I believe that they need more research before I add that part in, but they are morally identical to the OE tree; they are simple cheaper. So now I have: IMAGE
I have to ask myself if there is any occasion when OE ITEM and LE ITEM are not the same. I think they are EDITION ITEM, in fact, and there will be some overlap. So now, I think I have some idea of what needs to be done, and which tables will have to bear having more than one instance. Sorted? Well, no. I still need to write it. However, it is now tea-break time, and it would be a shame to waste that. Looking at it further, ITEM is confusing, and should be called PIECE. Finished LayoutIMAGE
|