Empress Justine

To preface everything, my entire sleep schedule has gotten a bit weird.

For a while, I’ve been staying up late and sleeping a bit late. It’s usually been staying up a bit past midnight then waking up before noon. Now it’s gotten less stable.

I’ve often stayed up well past midnight, then felt the need to skip sleeping later in the day. Sometimes I’m doing this with the goal of establishing a better bed time, by getting myself tired enough to sleep at an earlier time. That hasn’t consistently worked.

Laser Hair Removal Appointment

I had an 8:20am laser hair removal appointment on Saturday. Instead of sleeping for only a few hours, then crashing after I finished the appointment, I stayed up the entire night. While in a heavily used incontinence undergarment. I got a shower at 4:30am, drank a Monster, ate some mixed nut blends for breakfast, and drank another Monster at around 7:15am.

Then I went to the appointment, with zero sleep. I took a bottle of water with me, for hydration. I drank the water outside of my vehicle, while walking around as I waited for the facility to open. I had to pee badly before the session, so I made good use of their restroom right before the session. Then I had to pee badly in the middle of the session.

When I got home, I made good use of my incontinence undergarment, put bed sheets on my bed, then promptly passed out when I should have cleaned myself up. Slept until about 5pm. Very heavy sleep.

Uncovered SQLite Table Creation Script

I accessed the Python script that I used for the final project web application for my college course on Python. It’s posted below.

import sqlite3
conn = sqlite3.connect('SmallShops.db')
curs = conn.cursor()
curs.execute('''CREATE TABLE Inventory
    (inventoryID INTEGER PRIMARY KEY NOT NULL,
     inventoryName VARCHAR(80) NOT NULL,
     department VARCHAR(80) NOT NULL,
     inventoryPrice FLOAT NOT NULL,
     inventoryQuantity FLOAT NOT NULL,
     inventoryValue FLOAT NOT NULL)''')
curs.execute('''CREATE TABLE Users
    (userID INTEGER PRIMARY KEY NOT NULL,
     userName VARCHAR(80) NOT NULL,
     email VARCHAR(80) NOT NULL UNIQUE,
     loginPassword VARCHAR(40) NOT NULL,
     creditCard CHAR(16) NOT NULL,
     city VARCHAR(80) NOT NULL,
     state VARCHAR(80) NOT NULL,
     country VARCHAR(80) NOT NULL,
     address VARCHAR(80) NOT NULL,
     phone CHAR(10) NOT NULL)''')
curs.execute('''CREATE TABLE Orders
    (orderID INTEGER PRIMARY KEY NOT NULL,
     userID INTEGER NOT NULL,
     creditCard CHAR(16) NOT NULL,
     city VARCHAR(80) NOT NULL,
     state VARCHAR(80) NOT NULL,
     country VARCHAR(80) NOT NULL,
     address VARCHAR(80) NOT NULL,
     items VARCHAR(255) NOT NULL,
     pricePerItem VARCHAR(255) NOT NULL,
     quantityPerItem VARCHAR(255) NOT NULL,
     costPerItem VARCHAR(255) NOT NULL,
     originalQuantityPerItem VARCHAR(255) NOT NULL,
     originalValuePerItem VARCHAR(255) NOT NULL,
     alteredQuantityPerItem VARCHAR(255) NOT NULL,
     alteredValuePerItem VARCHAR(255) NOT NULL,
     totalCost FLOAT NOT NULL,
     orderDate DATE NOT NULL)''')
conn.close()

I decided to use SQL (or technically DML in this case, I suppose) directly in the Python scripts for the project.

There’s a known bug for SQLite in which you cannot manually set auto-increment for a primary key field. Primary keys auto-increment by default, so you just have to trust the system to work properly.

A few things that were fields should have been reserved for saved views. The derived fields should have exclusively been reserved for saved views as calculations built into the saved views.

There obviously should have been a fourth table to act as a bridge table for Orders and Inventory. Several fields should be eliminated from Orders so that the bridge table can assume its full role of accommodating many-to-many relationships.

Foreign key fields need to be officially established, but I don’t know how well that can be done with SQLite. This is particularly important for the bridge table, since the primary key for the bridge table will be a joint primary key that is two separate foreign keys, and the foreign key combination needs to be unique to eliminate data replication.

The current plan is to just take this database structure, redo it in a more ‘proper’ way, then experiment with it via the SQLite browser and Python scripts. It could also get translated into PostgreSQL. Since PostgreSQL has more thorough infrastructure, that could help to improve things.