Topic: Game project

[Elod-Hora]

0/1 - code for Master/Padawan, ID - is master's/padawan's Member ID.

[*<JO>*Lytali]

hmm so [0;ID] is a master
and [1;ID] is a padawan ?

[Elod-Hora]

Yup. So the first part is binary.

Of course, it's only the idea. I'm not quite sure how the programming stuff works.

[*<JO>*Lytali]

ok so if I understand correctly
Database will consist of 3 tables which are Events , Members and Relationships

Event :
MemberID, EventID, Date, text and type.
(MemberID, EventID) will be the primary key.

Members :
MemberID, firstname, lastname, planet of origin, portrait, Gender ,species, saber_color, DOB, current rank.
(memberID) is the primary key.

Relationships
MemberID, MemberID, type.
(MemberID, MemberID, type) is the primary key.


primary keys is just a thing used to order the tables
the quickest search is if you know the key or want a certain range of a key,
right now we are still developing the tool that will create the database but after it is done the main application (the game itself)
will only read/search the DB and never actually modify it so we might want to start thinking about indexes
such as if you want it to be faster to find events by Date then you can tell the DB to create another index for table Events that maps date->event which helps with performance over large data.

if this setup sounds fine to you then we should start discussing the data definition and manipulation language and what are the general features and syntax you are looking for 

[*<JO>*Narretas]

What about adding specific titles for members, aside from their ID. For example Master Silvaer as Best Fueled Efurrr (Or something classier) ans Master Cosmo being our greatest diplomat. Might be useful to leave room for those things?

[Elod-Hora]

This might be "Honorable title" and go in the "Members" table also. Good hint, Master Ek.

Padawan Lytali, I think you might give me an introduction to this part

[*<JO>*Lytali]

well the application is basically two very general abstract phases

a)Creating the Data

• Define Data
• Manipulate Data
• Link data together and make sure it makes sense ( semantic analysis)

b)Actually committing the data to disk
 

• Create actual Database
• Enter Data

so first order of business is coming up with the language that will enable us to define records and manipulate them later
and also link them this language needs to be simple enough to be easy to use , intuitive and hide any unnecessary low level details.

so lets start by saying what are the functions that can be done and do we want it to be simple or become somewhat of an actual scripting language

on the other hand we can eliminate that element and just expose the SQL language to the application user
in that case someone like my master would use SQL statements to add , update and manipulate records in each table , view them and in the end make sure that it all makes sense

[Elod-Hora]

Ok, let's come back to the initial design: page 2.

I think the database part of the project should be very end-user side. So that you have the following layout:

Member list
There's a blank window (maybe with a greyed out JO logo on the background) and a writing in center promts for a member name.

You can input ID, First name, Last name or First/last name together. Everything which is found from this query will be open in a short list, so you can select the correct one to watch/modify. If you type nothing, it outputs the whole list, separated in pages. The search result also contains a search window for additional search.

[I think that at this point of time advanced search (by some particular event/data piece, etc.) is not necessary... Or we also might design it too?]

In the search results there is also a button which leads to the member creation page.

Member creation page
There you only have to input SQL statements in a very straightforward way. In the end, you can:

* Save result - inputs everything to the database, outputs the member page.
* Discard changes - outputs the member page without saving.
* Clear - cancels member creation/modification, starting a new one.

On the member page
There is a button list which permits you to:
* Add event;
* Modify/delete existing event;
* Modify/delete member info (in a separate window)

Event creation page
Similar to the member creation page. Analog functionality.

Relationship can be defined in both event creation page (x takes y as his padawan) and member creation page (Please, input known master/s separating them by commas). The relationship created in the member creation page also creates an event with the blank additional info. [/u]

Coming to think again about events, we actually have to think better about them. Actual event table might not satisfy the needs.

As for now, I would define the event table as follows:
* MemberID - primary key
* EventID - primary key
* Type - variable list. On the type actually depends the following input treatment and data registration. Maybe subtables are more suitable? In that case you might actually put the type as the question: what kind of event is that, then redirect to the appropriate tables.

Ok, I'll think better about the event database and let you know. Tell me if what I exposed here is what you actually wanted to hear