BrickLink Discussion Forum

Discussion Forum: Messages by SylvainLS (46)

Redisplay Messages: Compact | Brief | All | Full Show Messages: All | Without Replies

Author:

SylvainLS

Posted:

Jun 20, 2020 15:06

Subject:

Re: Terminology - DB to organize my 100,000+ pcs

Viewed:

40 times

Topic:

Catalog

View

Cancel

BrickLink
ID Card

SylvainLS (46)

Location:

France, Nouvelle-Aquitaine

Member Since

Contact

Type

Status

Apr 25, 2014

Seller

Store: BuyerOnly

BrickLink Discussions Moderator (?)

In Catalog, mjah5 writes:

Hi all.
BACKGROUND: Let my start by saying that unlike my grandchildren, Marcus and
Soren, I am not a "Master Builder". I am a "Master Collector." My brick hobby
is to purchase long forgotten brick collections from parents of teen + former
brick fan that have been collecting dust in the basement or attic for years.
Once in my possession, I discard the fake pieces, wash the real ones then sort
them out looking for the special pieces that will tell me which sets the original
owner possessed.Then I try to re-assemble those sets.
PROBLEM: Currently, I have about 330 sets that I have identified as previously
owned. Those are my SIPs, "sets-in-progress." Each SIP has a container where
I store the parts that I've located. Together those 330 SIPs consist of
approximately 56,000 pieces. Of those, I have located about 23,000 pieces and
I am still looking for the other 23,000 pieces. I would guess my personal brick
collection consists of 100,000+ pieces that are not currently assigned to a SIP.
They are sorted and stored in other many other containers. When I need to locate
a piece for a SIP I look in about 5 "likely" containers then give up. Do I not
have the piece or is just in one of the many many "unlikely" containers?
SOLUTION: I'm building a MySQL Database to keep track of my collection.
Using BL's category system, there exist many bricks, slopes, arches etc.,
based more or less on shape. Within the sub-category bricks there are 1x1,
2x2, 2x4 etc., more or less based on size.
QUESTIONS: Q1;What are these sub-categories called? I would call them an ELEMENT.
is that correct? is there a better name for the sub-categories? Further, the
sub-categories such as 1x1 bricks of course come in many colours. Q2: What are
these sub-sub-categories called, or what are these ELEMENTs with a particular
colour called? I would call them a PART. Correct? Any other better name?
Q3; Lastly, if I hold in my hand, one blue 1x1 brick, what should that be called?
I would suggest that is a PIECE. Correct? Any better answer?
CATEGORY :: ELEMENT :: PART :: PIECE ??

First, that you have trouble finding names for your entities is a big clue they
are the wrong entities.

Vocabulary-wise, “element,” ”part” and “piece” are mostly the same thing.
LEGO uses “design” for the mould (and decor

) and “element” for design + colour.
LEGO’s “DesignID” is the number most often used by BL, LDraw and others as a
“part ID” or “name” (the text explaining the part is then a “description”).
And LEGO’s “ElementID,” the 6-digit number that appears in their instructions,
is what BL calls a PCC / Part-Colour-Code.

So, you found out that BL’s categories are “more or less based on shape.” That
means they aren’t.
Then you thought about colours. “Everybody knows” you don’t sort LEGO by colour

Then you found that many pieces share the same shape and are distinguished by
their size. Not all are.

So, what are you trying to do with this? Are you are trying to categorize your
parts to fit them in containers?
Then what you found out is that parts have attributes: general shape, size, colour,
and you “more or less” ordered them: shape first, then colour, then size.
Okay, that’s some sort of sieve system to define containers.
But why do you need to put that in you DB?

You have a list of parts of one side, your inventory, and lists of parts on the
other side, the wanted parts for the sets.
How will the database be used? You need to know first if the exact part (ID
+ colour) is in your inventory and, second, where it’s stored if it is.
Where do this categorization of yours is used in the DB?
Nowhere that I see.

Or do you want to have an algorithm that takes a BL part (ID + description +
colour) and turns out a container number?
But does it have to be in the DB? Not that I see.

So I don’t see a need to complicate your DB. You just need to have four main
tables: parts (BL id + description), colours, inventories (list of parts in a
given colour and in a given quantity), and containers (association between a
location and parts).

Besides, you’ll quickly find all “shapes” don’t divise regularly (or at all)
into “colours” or “sizes” (most of the heads are yellow; slopes first divise
by angle, not size; Technic connectors don’t come in many colours nor sizes; etc.).
Especially if you use BL categories as “shapes.”

On this note, here’s a rough categorization that some sellers (who sort many
parts) use as a first sieve:
  Bricks & Arches
  Brick Modified & Round
  Plate
  Plate Modified & Round
  Slope
  Technic
  Tile & Panel
  Minifig
  Other
They are about the same size in a “standard” collection. This might help you
devise your containers’ organization.