Skip to content

Commit

Permalink
Create SQL table definitions file (tables.sql)
Browse files Browse the repository at this point in the history 
This file has currently been populated with sql auto-generated from
the peewee models code. Please note that no changes have been made
to the auto-generated code yet, except for expanding it into many
lines for better readability. Further optimization will be following
soon in a series of commits, including changing the structure to
match the one discussed in the meeting of 2015-08-07....
  • Loading branch information
@badrihippo
badrihippo committed Aug 8, 2015
1 parent 92094fc commit da807d3
Showing 1 changed file with 158 additions and 0 deletions.
158 changes: 158 additions & 0 deletions growlinflask/tables.sql
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,158 @@
CREATE TABLE "group"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"position" INTEGER NOT NULL, "name" VARCHAR(128) NOT NULL,
"visible" SMALLINT NOT NULL
);

This comment has been minimized.

Sign in to view

Copy link
@badrihippo

badrihippo Aug 19, 2015

Author Owner

Here, can we have name as UserGroup for easy understanding. This will be a table with very rows. So why have an integer field as PK ? Can we not have groupname itself as PK ? This will avoid lookups to bring up the name. I am not clear on the fields position and visible. @KrishnaRamamoorthy

OK, I'll change the name to user_group (btw you can also do edits directly by clicking on the pencil button)

The reason for a separate name and id was that I thought renames would be easier if they were separate (plus @aparnaswamy was saying we should avoid non-integer pk's as much as possible). If you think renaming won't be such a problem (not a common operation or something) then I can merge the fields (or merge id with position; see below).

position is for determining the order in which the UserGroup appears on places like the login page (Sarala, Bilva, Tamala, Ashwatha; not Ashwatha, Bilva, Sarala, Tamala). Maybe the name can be changed to ordering or something if that'll make it more clear.

visible is to decide whether that UserGroup is visible in places like the login page or not. In case we want to hide the group but keep it internally for past records. I've actually created an "issue" on the question of storing past records; you can see (and discuss!) at: #3.
CREATE INDEX "group_name" ON "group" ("name");


CREATE TABLE "user"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"username" VARCHAR(32) NOT NULL,
"password" VARCHAR(512),
"group_id" INTEGER NOT NULL,
"refnum" VARCHAR(255),
"name" VARCHAR(64) NOT NULL,
"email" VARCHAR(64),
"phone" VARCHAR(16),
"birthday" DATE,
"active" SMALLINT NOT NULL,
FOREIGN KEY ("group_id") REFERENCES "group" ("id")
);
CREATE UNIQUE INDEX "user_username" ON "user" ("username");
CREATE INDEX "user_group_id" ON "user" ("group_id");

CREATE TABLE "publishplace"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"name" VARCHAR(512) NOT NULL

This comment has been minimized.

Sign in to view

Copy link
@badrihippo

badrihippo Aug 19, 2015

Author Owner

Here also we can remove the field id. Change the "name" field to call it place or something more relevant and make that as the PK @KrishnaRamamoorthy

Again, will having the name as the pk affect ease of edits? Or is it okay to do this in favour of lookup optimization? @Sachin0002 @aparnaswamy

I'd rather keep the field as name. It gets easier in the other code if the main identifiers are named consistently; otherwise I'll have to keep checking back to see what the property was called for that particular table (Item.title? Group.group_name? Publisher.publisher? Author.real_name?).
);
CREATE UNIQUE INDEX "publishplace_name" ON "publishplace" ("name");

CREATE TABLE "publisher"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"name" VARCHAR(256) NOT NULL,
"address" TEXT,
"imprint_of_id" INTEGER,
FOREIGN KEY ("imprint_of_id") REFERENCES "publisher" ("id")
);

This comment has been minimized.

Sign in to view

Copy link
@badrihippo

badrihippo Aug 19, 2015

Author Owner

@KrishnaRamamoorthy, replies below...

Name need not be 256. Maybe 128 ?

OK :)

Why e the field names as id and name in every table ? Can we not have more meaningful names as relevant for that table ?

As I said before, I'd prefer consistent naming for the columns. Unless you think it'll make the lookups too confusing?

Why address is text ? Why not varchar ?

Oh, that's right! :P I'll change it...

What is imprint of id ? I am not clear. Further, it ends up being circular reference.

Yes, I had added this earlier in case we wanted to track publishers being imprints of other publishers. I guess we can drop that for now... :octocat:
CREATE INDEX "publisher_imprint_of_id" ON "publisher" ("imprint_of_id");

CREATE TABLE "currency"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"name" VARCHAR(32) NOT NULL,
"symbol" VARCHAR(4) NOT NULL,
"conversion_factor" REAL NOT NULL

This comment has been minimized.

Sign in to view

Copy link
@badrihippo

badrihippo Aug 19, 2015

Author Owner

No need for id. Make the name , curr_name as PK
Conversion factor has no significance without a date. We discussed the other day and decided not to have it

OK. So in that case we need only the name and symbol fields?
);
CREATE UNIQUE INDEX "currency_name" ON "currency" ("name");


CREATE TABLE "author"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"name" VARCHAR(128) NOT NULL,
"is_pseudonym" SMALLINT NOT NULL,
"author_sort" VARCHAR(128) NOT NULL
);

This comment has been minimized.

Sign in to view

Copy link
@badrihippo

badrihippo Aug 19, 2015

Author Owner

We didnt discuss on the need for author master. Is it required ? Considering same author names may appear differently in different books, is it required to master this ? We need to know from Yasho. Also, is it there in Merlin now ?
Even if required, what is the need for the is_pseudonym and author-sort fields ?
@KrishnaRamamoorthy

Actually, the reason for this was partly because the current system wasn't working. I didn't realize it hadn't come up in the discussion (or had it? I thought I would have noticed it since it was already in the code). The problem Yasho had was that the name was written differently in different books. So it was hard to search by author because there were so many different versions of the names (Philip Pullman vs Pullman, Philip vs Philip P.) An author master would help because then all the names can be written (and therefore the authors can be referenced) more consistently.

The author_sort field is an auto-set, standardised version of the name (eg. Asimov, Isaac) which can be used for searches and sorting (sort by author). The name is the human-readable version, eg. Isaac Asimov. Actually this hasn't been thought out that well (do we really need a separate field for author as-it's-written-on-the-book?). The author_sort idea was based on what Calibre does for its books. On second thoughts, for our case it might be better to store the name standardised, and then later generate the human-readable version on-the-fly.

Fine, maybe there's no need to have is_pseudonym for now (at least, not unless we plan to store more detailed author profiles).

Anyway, if it wasn't discussed, maybe we should mark it for discussion in the next meeting?
CREATE INDEX "author_author_sort" ON "author" ("author_sort");


CREATE TABLE "location"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"name" VARCHAR(256) NOT NULL,
"prevent_borrowing" SMALLINT NOT NULL
);
CREATE UNIQUE INDEX "location_name" ON "location" ("name");

CREATE TABLE "publication"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"title" VARCHAR(512) NOT NULL,
"display_title" VARCHAR(256) NOT NULL,
"pubtype" VARCHAR(255),
"pubdata_id" INTEGER,
"identifier" VARCHAR(256),
"call_no" VARCHAR(8) NOT NULL,
"keywords" VARCHAR(1024),
"comments" TEXT
);

CREATE TABLE "copy"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"accession" INTEGER NOT NULL,
"item_id" INTEGER NOT NULL,
"location_id" INTEGER NOT NULL,
"copydata_type" VARCHAR(255),
"copydata_id" VARCHAR(255),
"price" REAL,
"price_currency_id" INTEGER,
"receipt_date" DATE,
"source" VARCHAR(512),
FOREIGN KEY ("item_id") REFERENCES "publication" ("id"),
FOREIGN KEY ("location_id") REFERENCES "location" ("id"),
FOREIGN KEY ("price_currency_id") REFERENCES "currency" ("id")
);
CREATE INDEX "copy_price_currency_id" ON "copy" ("price_currency_id");
CREATE UNIQUE INDEX "copy_accession" ON "copy" ("accession");
CREATE INDEX "copy_item_id" ON "copy" ("item_id");
CREATE INDEX "copy_location_id" ON "copy" ("location_id");


CREATE TABLE "borrowing"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"copy_id" INTEGER NOT NULL,
"user_id" INTEGER NOT NULL,
"group_id" INTEGER NOT NULL,
"borrow_date" DATETIME NOT NULL,
"renew_times" INTEGER NOT NULL,
"is_longterm" SMALLINT NOT NULL,
FOREIGN KEY ("copy_id") REFERENCES "copy" ("id"),
FOREIGN KEY ("user_id") REFERENCES "user" ("id"),
FOREIGN KEY ("group_id") REFERENCES "group" ("id"));
CREATE INDEX "borrowing_group_id" ON "borrowing" ("group_id");
CREATE INDEX "borrowing_user_id" ON "borrowing" ("user_id");
CREATE UNIQUE INDEX "borrowing_copy_id" ON "borrowing" ("copy_id");


CREATE TABLE "pastborrowing"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"accession" INTEGER NOT NULL, "user_id" INTEGER NOT NULL,
"group_id" INTEGER NOT NULL, "borrow_date" DATETIME NOT NULL,
"return_date" DATETIME NOT NULL,
FOREIGN KEY ("user_id") REFERENCES "user" ("id"),
FOREIGN KEY ("group_id") REFERENCES "group" ("id")
);
CREATE INDEX "pastborrowing_group_id" ON "pastborrowing" ("group_id");
CREATE INDEX "pastborrowing_user_id" ON "pastborrowing" ("user_id");


CREATE TABLE "copybook"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"pub_name_id" INTEGER, "pub_place_id" INTEGER,
"pub_date" DATE,
FOREIGN KEY ("pub_name_id") REFERENCES "publisher" ("id"),
FOREIGN KEY ("pub_place_id") REFERENCES "publishplace" ("id")
);
CREATE INDEX "copybook_pub_place_id" ON "copybook" ("pub_place_id");
CREATE INDEX "copybook_pub_name_id" ON "copybook" ("pub_name_id");


CREATE TABLE "pubperiodical"
(
"id" INTEGER NOT NULL PRIMARY KEY,
"cover_content" VARCHAR(512),
"issue" INTEGER,
"vol_no" INTEGER,
"vol_issue" INTEGER,
"date" DATE,
"date_hide_day" SMALLINT
);

9 comments on commit da807d3

@KrishnaRamamoorthy
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CREATE TABLE "group"
+(

  • "id" INTEGER NOT NULL PRIMARY KEY,
  • "position" INTEGER NOT NULL, "name" VARCHAR(128) NOT NULL,
  • "visible" SMALLINT NOT NULL
    +);

Here, can we have name as UserGroup for easy understanding. This will be a table with very rows. So why have an integer field as PK ? Can we not have groupname itself as PK ? This will avoid lookups to bring up the name. I am not clear on the fields position and visible.

@KrishnaRamamoorthy
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CREATE TABLE "publishplace"
+(

  • "id" INTEGER NOT NULL PRIMARY KEY,
  • "name" VARCHAR(512) NOT NULL
    +);
    Here also we can remove the field id. Change the "name" field to call it place or something more relevant and make that as the PK

@KrishnaRamamoorthy
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CREATE TABLE "publisher"
+(

  • "id" INTEGER NOT NULL PRIMARY KEY,
  • "name" VARCHAR(256) NOT NULL,
  • "address" TEXT,
  • "imprint_of_id" INTEGER,
  1. Name need not be 256. Maybe 128 ?
  2. Why e the field names as id and name in every table ? Can we not have more meaningful names as relevant for that table ?
  3. Why address is text ? Why not varchar ?
  4. What is imprint of id ? I am not clear. Further, it ends up being circular reference.

@KrishnaRamamoorthy
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CREATE TABLE "currency"
+(

  • "id" INTEGER NOT NULL PRIMARY KEY,
  • "name" VARCHAR(32) NOT NULL,
  • "symbol" VARCHAR(4) NOT NULL,
  • "conversion_factor" REAL NOT NULL
    +);
  • No need for id. Make the name , curr_name as PK
  • Conversion factor has no significance without a date. We discussed the other day and decided not to have it

@KrishnaRamamoorthy
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CREATE TABLE "author"
+(

  • "id" INTEGER NOT NULL PRIMARY KEY,
  • "name" VARCHAR(128) NOT NULL,
  • "is_pseudonym" SMALLINT NOT NULL,
  • "author_sort" VARCHAR(128) NOT NULL
    +);
    +CREATE INDEX "author_author_sort" ON "author" ("author_sort");
  • We didnt discuss on the need for author master. Is it required ? Considering same author names may appear differently in different books, is it required to master this ? We need to know from Yasho. Also, is it there in Merlin now ?
  • Even if required, what is the need for the is_pseudonym and author-sort fields ?

@KrishnaRamamoorthy
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Location table also doesnt need id and name separately

@KrishnaRamamoorthy
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We didnt list down publication as a master table. Would like to know more about the need for this table

@KrishnaRamamoorthy
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont see tables for user role, genre and item type. Please create them

@badrihippo
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@KrishnaRamamoorthy: I've put more replies inline. The publication table was from the auto-generated code; I had already removed in the next commit (f0b1cbb). User Role is being implemented using a framework (Flask-Principal), so I'll have to learn how that works before including it into the table. I'll add genre and item type: thanks for pointing those out.

Please sign in to comment.