If I made a list of knitting stitches, what information would belong in that list? What information would belong in separate, related lists?
Analyzing the attributes of data, in this case attributes of a knitting stitch pattern, is referred to as normalizing the data. The attributes get sorted into tables. The ideal condition is to remove redundancy in the tables by putting the attributes that have redundant values in separate tables. In most cases a condition known as 3rd normal form is the sweet spot of normalization. There are higher levels of normalization. Those higher levels are the concern of mathematicians with autistic savant tendencies. Even when trying to apply 3rd normal form it is not uncommon to cheat a bit.
A knitting stitch has a name. Some knitting stitches have more than one name. Does the knitting stitch have a name or does the name have a knitting stitch?
For the purpose of making a database table (list) of knitting stitches and the attributes of the knitting stitch, it works out better to treat the name as if it has a knitting stitch. Because this can create a wrinkle when, later, associating other features of a knitting stitch pattern, the knitting stitch name is not the best way to define the relationship between a knitting stitch name and, for example, the rows that are included in the instructions for the knitting stitch. To manage the wrinkle an artificial key field is included. The artificial key is a Stitch ID or record number. The database management system has tools that automatically create the next record number. That automation relieves the person entering data from keeping track of what the last number was.
Stitch ID |
Stitch Name |
1 |
One x One Ribbing |
2 |
Knit One Purl One Ribbing |
3 |
Trinity 1 |
4 |
Trinity 2 |
5 |
Bramble |
In this example Stitch IDs 1 and 2 describe two names that refer to the same knitting stitch pattern.
Trinity 1 and Bramble are also two names for the same knitting stitch pattern.
Remember what was said above about cheating a bit? Trinity is also the name given for more than one unique knitting stitch pattern. Rather than trying to normalize to a higher level, this example uses a numeral following the name to give each unique stitch patterns a unique version of the name.
Another set of attributes for a stitch pattern describes the number of stitches and rows that make up the stitch pattern. Stitches and rows have a number of stitches and rows that are repeated when working the pattern. There may also be some 'plus' stitches or rows. The 'plus' stitches and 'plus' rows are not repeated. The plus stitches help to maintain a symmetry on the edges of a knitted fabric. Plus stitches are often found on lace and cable patterns. Plus rows are sometimes used to create a 'foundation' for a pattern. Often there are no plus stitches or rows.
Stitch ID |
Stitch Name |
Stitches |
StitchesPlus |
Rows |
RowsPlus |
1 |
One x One Ribbing |
2 |
0 |
1 |
0 |
2 |
Knit One Purl One Ribbing |
2 |
0 |
1 |
0 |
3 |
Trinity 1 |
4 |
0 |
4 |
0 |
4 |
Trinity 2 |
4 |
1 |
4 |
0 |
5 |
Bramble |
4 |
0 |
4 |
0 |
At this time the stitch name table in Knittingfool.com has the following structure:
[RecNum] [int] IDENTITY(1,1)
[StitchName] [nvarchar](255)
[Stitches] [varchar](35)
[StCount] [smallint]
[StitchesPlus] [smallint]
[Rows] [smallint]
[RowsPlus] [smallint]
[Category] [nvarchar](50)
[attribution] [varchar](255)
[URLCode] [int]
[picture] [varchar](200)
[h1] [int]
[w1] [int]
[memberflag] [int]
[picture2] [varchar](200)
[attribution2] [varchar](100)
[attribution3] [varchar](100)
[symbolstatus] [smallint]
[graphic] [varchar](200)
[thumbnail] [varchar](200)
[ChangeDate] [datetime]
Some of these fields, such as URL Code and membership flag, are artifacts from earlier development experiments that are no longer used. They should be removed but there is always extra caution surrounding removal of fields, so it doesn't get done until there is a major rewrite.
Stitches and StCount are redundant. There was a reason to have both. Note that one is a varchar (i.e., a text or a string value) and the other is a small int (i.e., a number value. I would have to research where these values are used in the code to refresh my memory about these two fields.
Some fields are not normalized very well. For example, picture and picture2 should be in a separate table. The same is true regarding the attribution fields. There are a lot of things I would do differently if I did the whole thing over again. Most programmers cringe a little when they review code they wrote years ago.