I have a kind of graph, composed of 5 kinds of objects, 1 of them is a link type of object, and the others are the 4 different types of 'nodes' between links.
Each of the 5 is so different that will have a different table.
Each 'node' will have 0..N links 'below', while each link will have exactly 1 'node' below (but of any of 4 kinds). Only things below need to be stored.
So my question is this, is it better in the link table to create 4 columns (node1, node2, node3, node4), and leave 3 of them NULL, the other containing the id of the node, or is it better to have 2 columns (nodetype, nodeId), where 1 tells wich table to search and the other the Id.
For the 0..N relationship I will have to create a new table I supose, but maybe just one to be shared by the 4 types of node.
Read the following for some ideas on how to handle polymorphism in DBs
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/inheritance.html
Related
I have a table named [Purpose] and another one named [PurposeMoviment].
Each Time a Purpose is edited (values, products, services, deadline, etc.), the PurposeMoviment will be generated.
Can I have PurposeMoviment with 2 pk columns (Purpose_ID, PurposeMoviment_ID) where PurposeMoviment is manually created by my system?
When I say manually created, is a simple GetLastPurposeMoviment + 1.
Its safe?
I'm asking because I want to show the actual number of moviments, like 1, 2, 3 ... Using identity, the moviment number will be 1 ... 4 ... 193.
Where I'm wrong?
Thanks
EDIT
I'm new to big environments and afraid about many peoples press the button to insert purpose at same time and make my manual-increment fails.
I'm using MVC5, Entity Framework 6 and Repository Pattern.
Thanks guys
I'm currently working on a project in which I'm going to need to create a binary-tree structure on a model. It's something similar to "A person can have 2 friends. Each of those 2 friends are persons as well, so they can also have 2 friends each one." Finally I will need to do a depth-first node search.
I want to do a depth search up to 4 levels, and I also want to know if any of the levels are uncompleted, for example:
person(root)
person(branch A) person(branch B)
person person person person
person person person person (no children) (only 1 child)person
as you can see, branch A is complete up to 4 levels. but branch B is not.
I'm guessing the way to know which branch is complete and which one isn't is to verify using empty() function on the array, something like:
$person = $this->Person->find('first', $conditions);
if(empty($person['Person']['friend_1']))
$uncomplete = true;
I'm missing the algorithm to iterate through nodes here, but what I really need is how do I retrieve 4 depths of hasOne / belongsTo (not sure which one is it), is it setting Model::recursive = 4?
Any suggestions are appreciated, thanks
in Cake we don't have recursive 4. recursive used for associated tables which are associated to current table (other meaning Model behavior) which can be between -1 to 2.
and also regarding to your table structure. please read the cake documents here to see which one one this is suits your table structure. In cake we have 3 kind of model structure. e.g. $actsAs = Tree or Containable or Translate
look at these question and article also:
Reference 1
Reference 2
Reference 3
I'm not sure if the following two relations are compatible for a union:
R: <- schema name
B
1
2
2
3
3
And:
Q: -< schema name
A B
5 1
6 1
4 2
3 4
I want to do the union: Q U R. Can I? What's the result?
The union operator requires that both relations are union-compatible. This means that they are required to have the same set of attributes. Note that this concept goes slightly beyond than sharing the same amount of attributes. This is because it also considers the content of the attribute.
This doesn't mean that both attributes should have the same name but rather that both attributes should, and I'm really walking away from relational algebra with this example, have a similar "data type". There is no such a thing in relation algebra but I think that if you have a programming background you'll easily get it by thinking on that concept.
EG: Consider the following relations:
Person(FirstName, LastName)
Country(Name, Population)
In this case, Person and Country are not union-compatible as they do not share the same set of attributes, even though they share the same amount of attributes.
In fact, these two relations are not compatible for a union: they have a different number of attributes. Found the answer after some more research.
Two table are said to be union compatible if both the table have same number of attributes (column) and corresponding attributes have the same data type (int,char,float,date etc.). Corresponding attributes means first attributes of both relations, then second and so
on.
union compatible:
A: (First_name (char), Last_name(char), Date_of_Birth(date))
B: (FName(char),LName(char),DOB(date))
Both table have 3 attributes and of same date type.
Not compatible:
A: (First_name (char), Last_name(char), Date_of_Birth(date))
B: (FName(char),LName(char),PhoneNumber(number))
(The third attributes are different.)
Check here for more detailed definition of Union Compatibility
In your case the two relations which you mentioned are not Union Compatibility because they do not have same number of attributes [schema R have one one attribute and schema Q have two attributes]
So you can not apply UNION operation on those schemas.
Preface: I don't have experience with rules engines, building rules, modeling rules, implementing data structures for rules, or whatnot. Therefore, I don't know what I'm doing or if what I attempted below is way off base.
I'm trying to figure out how to store and process the following hypothetical scenario. To simplify my problem, say that I have a type of game where a user purchases an object, where there could be 1000's of possible objects, and the objects must be purchased in a specified sequence and only in certain groups. For example, say I'm the user and I want to purchase object F. Before I can purchase object F, I must have previously purchased object A OR (B AND C). I cannot buy F and A at the same time, nor F and B,C. They must be in the sequence the rule specifies. A first, then F later. Or, B,C first, then F later. I'm not concerned right now with the span of time between purchases, or any other characteristics of the user, just that they are the correct sequence for now.
What is the best way to store this information for potentially thousands of objects that allows me to read in the rules for the object being purchased, and then check it against the user's previous purchase history?
I've attempted this, but I'm stuck at trying to implement the groupings such as A OR (B AND C). I would like to store the rules in a database where I have these tables:
Objects
(ID(int),Description(char))
ObjectPurchRules
(ObjectID(int),ReqirementObjectID(int),OperatorRule(char),Sequence(int))
But obviously as you process through the results, without the grouping, you get the wrong answer. I would like to avoid excessive string parsing if possible :). One object could have an unknown number of previous required purchases. SQL or psuedocode snippets for processing the rules would be appreciated. :)
It seems like your problem breaks down to testing whether a particular condition has been satisfied.
You will have compound conditions.
So given a table of items:
ID_Item Description
----------------------
1 A
2 B
3 C
4 F
and given a table of possible actions:
ID_Action VerbID ItemID ConditionID
----------------------------------------
1 BUY 4 1
We construct a table of conditions:
ID_Condition VerbA ObjectA_ID Boolean VerbB ObjectB_ID
---------------------------------------------------------------------
1 OWNS 1 OR MEETS_CONDITION 2
2 OWNS 2 AND OWNS 3
So OWNS means the id is a key to the Items table, and MEETS_CONDITION means that the id is a key to the Conditions table.
This isn't meant to restrict you. You can add other tables with quests or whatever, and add extra verbs to tell you where to look. Or, just put quests into your Items table when you complete them, and then interpret a completed quest as owning a particular badge. Then you can handle both items and quests with the same code.
This is a very complex problem that I'm not qualified to answer, but I've seen lots of references to. The fundamental problem is that for games, quests and items and "stats" for various objects can have non-relational dependencies. This thread may help you a lot.
You might want to pick up a couple books on the topic, and look into using LUA as a rules processor.
Personally I would do this in code, not in SQL. Each item should be its own class implementing an interface (i.e. IItem). IItem would have a method called OkToPurchase that would determine if it is OK to purchase that item. To do that, it would use one or more of a collection of rules (i.e. HasPreviouslyPurchased(x), CurrentlyOwns(x), etc.) that you can build.
The nice thing is that it is easy to extend this approach with new rules without breaking all the existing logic.
Here's some pseudocode:
bool OkToPurchase()
{
if( HasPreviouslyPurchased('x') && !CurrentlyOwns('y') )
return true;
else
return false;
}
bool HasPreviouslyPurchased( item )
{
return purchases.contains( item )
}
bool CurrentlyOwns( item )
{
return user.Items.contains( item )
}
I have a question taken from pg 16 of IBM's Nested Relational Database White Paper, I'm confused why in the below CREATE command they use MV/MS/MS rather than MV/MV/MS, when both ORDER_#, and PART_# are one-to-many relationships.. I don't understand what value, vs sub-value means in non-1nf database design. I'd also like to know to know more about the ASSOC () clause.
Pg 16 of IBM's Nested Relational Database White Paper (slight whitespace modifications)
CREATE TABLE NESTED_TABLE (
CUST# CHAR (9) DISP ("Customer #),
CUST_NAME CHAR (40) DISP ("Customer Name"),
ORDER_# NUMBER (6) DISP ("Order #") SM ("MV") ASSOC ("ORDERS"),
PART_# NUMBER (6) DISP (Part #") SM ("MS") ASSOC ("ORDERS"),
QTY NUMBER (3) DISP ("Qty.") SM ("MS") ASSOC ("ORDERS")
);
The IBM nested relational databases implement nested tables as repeating attributes and
repeating groups of attributes that are associated. The SM clauses specify that the attribute is either repeating (multivalued--"MV") or a repeating group (multi-subvalued--"MS"). The ASSOC clause associates the attributes within a nested table. If desired, the IBM nested relational databases can support several nested tables within a base table. The following standard SQL statement would be required to process the 1NF tables of Figure 5 to produce the report shown in Figure 6:
SELECT CUSTOMER_TABLE.CUST#, CUST_NAME, ORDER_TABLE.ORDER_#, PART_#, QTY
FROM CUSTOMER_TABLE, ORDER_TABLE, ORDER_CUST
WHERE CUSTOMER_TABLE.CUST_# = ORDER_CUST.CUST_# AND ORDER_CUST.ORDER_# =
ORDER _TABLE.ORDER_#;
Nested Table
Customer # Customer Name Order # Part # Qty.
AA2340987 Zedco, Inc. 93-1123 037617 81
053135 36
93-1154 063364 32
087905 39
GV1203948 Alphabravo 93-2321 006776 72
055622 81
067587 29
MT1238979 Trisoar 93-2342 005449 33
036893 52
06525 29
93-4596 090643 33
I'll go ahead and answer my own question, while pursuing IBM's UniVerse SQL Administration for DBAs I came across code for CREATE TABLE on pg 55.
ACT_NO INTEGER FORMAT '5R' PRIMARY KEY
BADGE_NO INTEGER FORMAT '5R' PRIMARY KEY
ANIMAL_ID INTEGER FORMAT '5L' PRIMARY KEY
(see distracting side note below) This amused me at first, but essentially I believe this to be a column directive the same as a table directive like PRIMARY ( ACT_NO, BADGE_NO, ANIMAL_ID )
Later on page 5-19, I saw this
ALTER TABLE LIVESTOCK.T ADD ASSOC VAC_ASSOC (
VAC_TYPE KEY, VAC_DATE, VAC_NEXT, VAC_CERT
);
Which leads me to believe that tacking on ASSOC (VAC_ASSOC) to a column would be the same... like this
CREATE TABLE LIVESTOCK.T (
VAC_TYPE ... ASSOC ("VAC_ASSOC")
VAC_DATE ... ASSOC ("VAC_ASSOC")
VAC_NEXT ... ASSOC ("VAC_ASSOC")
VAC_cERT ... ASSOC ("VAC_ASSOC")
);
Anyway, I'm not 100% sure I'm right, but I'm guessing the order doesn't matter, and that rather than these being an intransitive association they're just a order-insensitive grouping.
Onward! With the second part of the question pertaining to MS and MV, I for the life of me can not figure out where the hell IBM got this syntax from. I believe it to be imaginary. I don't have access to a dev machine I can play on to test this out, but I can't find it (the term MV) in the old 10.1 or the new UniVerse 10.3 SQL Reference
side note for those not used to UniVerse the 5R and 5L mean 5 characters right or left justified. That's right a display feature built into the table meta data... Google for UniVerse FORMAT (or FMT) for more info.
Just so you know, Attribute, Multivalue and Sub-Multivalue comes from the way they structure their data.
Essentially, all data is stored in a tree of sorts.
UniVerse is a Multivalue Database. Generally, it does not work in the say way as Relational DBs of the SQL work function.
Each record can have multiple attributes.
Each attribute can have multiple multivalues.
Each multivalue can have multiple sub-multivalues.
So, if I have a record called FRED
Then, FRED<1,2,3> refers to the 1st attribute, 2 multivalue position and 3 subvalue position.
To read more about it, you need to learn more about how UniVerse works. The SQL section is just a side part of it. I suggest you read the other manuals to understand what you are working with.
EDIT
Essentially, the code above is telling you that:
There may be multiple orders per client. These are stored at an MV level in the 'table'
There may be multiple parts per order. These are stored at the MS level in the 'table'
There may be multiple qtys per order. These are stored at the MS level in the 'table'. since they are at the same level, although they are 1-n for orders, they are 1-1 in regards to parts.