| Groups | Blog | Home |
sql server (alternate) : Eliminating Combinatorial Relationship Multiplication
are arranged in a tree. Each organization has only one parent organization but a user maybe a member of multiple organizations. The problem that I'm facing that both organizations and individual users may have relationships with other entities which are semantically the same. For instance, an individual user can purchase things and so can an organization. An individual user can have business partners and so can an organization. So it seems that I would need to have a duplicate set of link tables that link a user to a purchase and then a parallel link table linking an organization to a purchase. If I have N entities with which both users and organizations may have relationships then I need 2*N link tables. There is nothing wrong with that per se but just not elegant to have two different tables for a relationship which is the same in nature, e.g. purchaser->purchaseditem. One other approach I was thinking of is to create an intermediate entity (say it's called "holder") that will be used to hold references to all the relationships that both an organization and an individual may have. There will be 2 link tables linking organizations to "holder" and users to "holder". Holder will in turn reference the purchases, partners and so on. In this case the number of link tables will be N+2 as opposed to 2*N but it will have a performance cost of an extra join. Is there a better way of modelling this notion of 2 different entities
[quoted text, click to view]
"Jeff Lanfield" <jlanfield2003@yahoo.com> wrote in message news:235c483f.0406301220.1e41d7c4@posting.google.com... > Suppose I have users that can belong to organizations. Organizations > are arranged in a tree. Each organization has only one parent > organization but a user maybe a member of multiple organizations. > > The problem that I'm facing that both organizations and individual > users may have relationships with other entities which are > semantically the same. For instance, an individual user can purchase > things and so can an organization. An individual user can have > business partners and so can an organization. So it seems that I would > need to have a duplicate set of link tables that link a user to a > purchase and then a parallel link table linking an organization to a > purchase. If I have N entities with which both users and organizations > may have relationships then I need 2*N link tables. There is nothing > wrong with that per se but just not elegant to have two different > tables for a relationship which is the same in nature, e.g. > purchaser->purchaseditem. > > One other approach I was thinking of is to create an intermediate > entity (say it's called "holder") that will be used to hold references > to all the relationships that both an organization and an individual > may have. There will be 2 link tables linking organizations to > "holder" and users to "holder". Holder will in turn reference the > purchases, partners and so on. In this case the number of link tables > will be N+2 as opposed to 2*N but it will have a performance cost of > an extra join. This is common scenario for a Customer, for example, where the Customer can then be either an organization or an individual. [quoted text, click to view] > Is there a better way of modelling this notion of 2 different entities > that can possess similar relationships with N other entities? If you are just looking to model it, then using an interface/implementation approach would work where you have Customer (Holder) as an interface and Organization and Person both implementing that interface. You could toss in an abstract class (partial implementation of the Interface) for the relationship implementations and extend that too. This is more handily modeled in UML OO types of diagrams than with relations, it seems to me. But, if you are looking to model it in order to implement in a SQL database then I think you are headed down the right path with your Holder pattern, although there could be other approaches that I'm missing too. I'd suggest putting some work into picking a meaningful name for the Holder relation (for example, it makes complete sense to everyone that a Customer could be a person or an org). Cheers! --dawn
[quoted text, click to view] "Jeff Lanfield" <jlanfield2003@yahoo.com> wrote in message news:235c483f.0406301220.1e41d7c4@posting.google.com... > Suppose I have users that can belong to organizations. Organizations > are arranged in a tree. Each organization has only one parent > organization but a user maybe a member of multiple organizations. > > The problem that I'm facing that both organizations and individual > users may have relationships with other entities which are > semantically the same. For instance, an individual user can purchase > things and so can an organization. An individual user can have > business partners and so can an organization. So it seems that I would > need to have a duplicate set of link tables that link a user to a > purchase and then a parallel link table linking an organization to a > purchase. If I have N entities with which both users and organizations > may have relationships then I need 2*N link tables. There is nothing > wrong with that per se but just not elegant to have two different > tables for a relationship which is the same in nature, e.g. > purchaser->purchaseditem. > > One other approach I was thinking of is to create an intermediate > entity (say it's called "holder") that will be used to hold references > to all the relationships that both an organization and an individual > may have. There will be 2 link tables linking organizations to > "holder" and users to "holder". Holder will in turn reference the > purchases, partners and so on. In this case the number of link tables > will be N+2 as opposed to 2*N but it will have a performance cost of > an extra join. > > Is there a better way of modelling this notion of 2 different entities > that can possess similar relationships with N other entities? You need to convert the following into an ERD. I've supplied particpation (may) constraints and cardinality constraints. Once the ERD is done, it is a snap to convert to a relational schema. PEOPLE n (may) have m BUSINESS_PARTNERS ORGANIZATIONS n (may) have BUSINESS_PARTNERS PEOPLE n (may) belong_to m ORGANIZATIONS PEOPLE 1 (may) buy n GOODS ORGANIZATIONS 1 (may) buy n GOODS So, in mock pseudo ERD form: PEOPLE == >have m:n ==> BUSINESS_PARTNERS <== n:m have <== ORGANIZATIONS " ==> people_order ==> 1:m GOODS m:1 <== orgs_order <== " So, you wind up with PEOPLE person_id PK etc ORGANIZATIONS org_id PK etc BUSINESS_PARTNERS person_id PK (FK) org_id PK (FK) GOODS item_id (PK) description etc PEOPLE_ORDER order_id PK person_id (FK) item_id (FK) order_date etc You can now either create an ORGS_ORDER table, or add in org_id to the PEOPLE_ORDER table, and change the table name to ORDER. This is a decsion based on many things, primarily the semantics of person_id and org_id. If they are mutually exclusive, then you can combine the tables simply by adding org_id. If they are not mutually exclusive, a horrible option is to add a flag to the ORDERS table, indicating whether the order is from a person or an organization. Don't do it.
Here is the link on Amazon.com for my new book on "Trees & Hierarchies
in SQL" http://www.amazon.com/exec/obidos/tg/detail/-/1558609202/qid=1080772873/sr=1-1/ref=sr_1_1/102-7683601-6345721?v=glance&s=books#product-details Separate the tree structure from the nodes. Ilike the nested sets model for the structure, but you can pick whatever works best for your situation. Then the nodes can go into another table. The classic scenario calls for a root class with all the common attributes and then specialized sub-classes under it. As an example, let's take the class of Vehicles and find an industry standard identifier (VIN), and add two mutually exclusive sub-classes, Sport utility vehicles and sedans ('SUV', 'SED'). CREATE TABLE Vehicles (vin CHAR(17) NOT NULL PRIMARY KEY, vehicle_type CHAR(3) NOT NULL CHECK(vehicle_type IN ('SUV', 'SED')), UNIQUE (vin, vehicle_type), ..); Notice the overlapping candidate keys. I then use a compound candidate key (vin, vehicle_type) and a constraint in each sub-class table to assure that the vehicle_type is locked and agrees with the Vehicles table. Add some DRI actions and you are done: CREATE TABLE SUV (vin CHAR(17) NOT NULL PRIMARY KEY, vehicle_type CHAR(3) DEFAULT 'SUV' NOT NULL CHECK(vehicle_type = 'SUV'), UNIQUE (vin, vehicle_type), FOREIGN KEY (vin, vehicle_type) REFERENCES Vehicles(vin, vehicle_type) ON UPDATE CASCADE ON DELETE CASCADE, ..); CREATE TABLE Sedans (vin CHAR(17) NOT NULL PRIMARY KEY, vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL CHECK(vehicle_type = 'SED'), UNIQUE (vin, vehicle_type), FOREIGN KEY (vin, vehicle_type) REFERENCES Vehicles(vin, vehicle_type) ON UPDATE CASCADE ON DELETE CASCADE, ..); I can continue to build a hierarchy like this. For example, if I had a Sedans table that broke down into two-door and four-door sedans, I could a schema like this: CREATE TABLE Sedans (vin CHAR(17) NOT NULL PRIMARY KEY, vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL CHECK(vehicle_type IN ('2DR', '4DR', 'SED')), UNIQUE (vin, vehicle_type), FOREIGN KEY (vin, vehicle_type) REFERENCES Vehicles(vin, vehicle_type) ON UPDATE CASCADE ON DELETE CASCADE, ..); CREATE TABLE TwoDoor (vin CHAR(17) NOT NULL PRIMARY KEY, vehicle_type CHAR(3) DEFAULT '2DR' NOT NULL CHECK(vehicle_type = '2DR'), UNIQUE (vin, vehicle_type), FOREIGN KEY (vin, vehicle_type) REFERENCES Sedans(vin, vehicle_type) ON UPDATE CASCADE ON DELETE CASCADE, ..); CREATE TABLE FourDoor (vin CHAR(17) NOT NULL PRIMARY KEY, vehicle_type CHAR(3) DEFAULT '4DR' NOT NULL CHECK(vehicle_type = '4DR'), UNIQUE (vin, vehicle_type), FOREIGN KEY (vin, vehicle_type) REFERENCES Sedans (vin, vehicle_type) ON UPDATE CASCADE ON DELETE CASCADE, ..); The idea is to build a chain of identifiers and types in a UNIQUE() constraint that go up the tree when you use a REFERENCES constraint. Obviously, you can do variants of this trick to get different class structures. If an entity doesn't have to be exclusively one subtype, you play with the root of the class hierarchy: CREATE TABLE Vehicles (vin CHAR(17) NOT NULL, vehicle_type CHAR(3) NOT NULL CHECK(vehicle_type IN ('SUV', 'SED')), PRIMARY KEY (vin, vehicle_type), ..); Now start hiding all this stuff in VIEWs immediately and add an
[quoted text, click to view]
--CELKO-- wrote: > Here is the link on Amazon.com for my new book on "Trees & Hierarchies > in SQL" > > http://www.amazon.com/exec/obidos/tg/detail/-/1558609202/qid=1080772873/sr=1-1/ref=sr_1_1/102-7683601-6345721?v=glance&s=books#product-details > > Separate the tree structure from the nodes. Ilike the nested sets > model for the structure, but you can pick whatever works best for your > situation. Then the nodes can go into another table. <snip a clever way of storing tree structures> I have a couple of questions: 1. What's to stop you putting extra information into the Sedans or SUV tables (like descriptions etc.) instead of creating separate tables? 2. Do you think it would be good to have primary keys that span two tables in order to get rid of the vehicles table? Would there be any disadvantage to doing it this way instead of the way you outlined? John
[quoted text, click to view]
> Separate the tree structure from the nodes. Ilike the nested sets > model for the structure, but you can pick whatever works best for your > situation. Then the nodes can go into another table. > > The classic scenario calls for a root class with all the common > attributes and then specialized sub-classes under it. The problem I described was not so much with modelling the tree (thanks partly to tips from your book which I do own) but with 2 entities having semantically identical relationships with N other entities. In my case the 2 entities are nodes and leaves - organizations and users. For simplicity of the example I'll use the path enumeration model (I know nested set is better). create table organizations (int id, varchar name ... etc) create table users (int id, varchar name ... etc) create table orgtree (varchar path, int orgId) create table members (int orgId, int userId) // which organizations a user belongs to create table partners (int id, ... etc) create table purchases (int id, ... etc) create table customers (int id, ... etc) The problem is that both users and organizations can have relationships with partners, purchases, and customers. Thus I have to have 2*N = 6 link tables to represent that. This example is simplified, in reality I have about 12 entities with which both organizations and users can have relationships so I have to have 24 link tables. Nothing wrong with that per se but I just think it is inelegant. In OO technology there are standard solutions for this kind of thing but in SQL the only approach I could think of is to introduce an "intermediate" entity (say it's called "holder") which will hold the references to the relationships that both a user and an organization can have. Users and Organizations can then in turn have a relationship with this "holder" entity. Thus the number of link tables will be N + 2 or 14 instead of 24. My question is: Are there any other approaches to this problem? Seems like a fairly common issue. Thanks! Jeff P.S. CELKO, I have to deal with tree stuff in SQL a lot and I originally I bought your book simply because there was nothing else on the topic and I looked hard both recently and in the past! I did not have high expectations because I thought it was just a quickie to capitalize on success of "SQL for smarties" but I was pleasently surprised: as the title suggests, it is definitely the most comprehensive compilation of SQL techiques for modelling trees in relational structures all gathered in one place that I ever saw. Well worth the price,thanks for putting it together! [quoted text, click to view] jcelko212@earthlink.net (--CELKO--) wrote in message news:<18c7b3c2.0407010727.4fbb407d@posting.google.com>...
> Here is the link on Amazon.com for my new book on "Trees & Hierarchies > in SQL" > > http://www.amazon.com/exec/obidos/tg/detail/-/1558609202/qid=1080772873/sr=1-1/ref=sr_1_1/102-7683601-6345721?v=glance&s=books#product-details > > Separate the tree structure from the nodes. Ilike the nested sets > model for the structure, but you can pick whatever works best for your > situation. Then the nodes can go into another table. > > The classic scenario calls for a root class with all the common > attributes and then specialized sub-classes under it. As an example, > let's take the class of Vehicles and find an industry standard > identifier (VIN), and add two mutually exclusive sub-classes, Sport > utility vehicles and sedans ('SUV', 'SED'). > > CREATE TABLE Vehicles > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) NOT NULL > CHECK(vehicle_type IN ('SUV', 'SED')), > UNIQUE (vin, vehicle_type), > ..); > > Notice the overlapping candidate keys. I then use a compound candidate > key (vin, vehicle_type) and a constraint in each sub-class table to > assure that the vehicle_type is locked and agrees with the Vehicles > table. Add some DRI actions and you are done: > > CREATE TABLE SUV > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT 'SUV' NOT NULL > CHECK(vehicle_type = 'SUV'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Vehicles(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > CREATE TABLE Sedans > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL > CHECK(vehicle_type = 'SED'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Vehicles(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > I can continue to build a hierarchy like this. For example, if I had > a Sedans table that broke down into two-door and four-door sedans, I > could a schema like this: > > CREATE TABLE Sedans > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL > CHECK(vehicle_type IN ('2DR', '4DR', 'SED')), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Vehicles(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > CREATE TABLE TwoDoor > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT '2DR' NOT NULL > CHECK(vehicle_type = '2DR'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Sedans(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > CREATE TABLE FourDoor > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT '4DR' NOT NULL > CHECK(vehicle_type = '4DR'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Sedans (vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > The idea is to build a chain of identifiers and types in a UNIQUE() > constraint that go up the tree when you use a REFERENCES constraint. > Obviously, you can do variants of this trick to get different class > structures. > > If an entity doesn't have to be exclusively one subtype, you play with > the root of the class hierarchy: > > CREATE TABLE Vehicles > (vin CHAR(17) NOT NULL, > vehicle_type CHAR(3) NOT NULL > CHECK(vehicle_type IN ('SUV', 'SED')), > PRIMARY KEY (vin, vehicle_type), > ..); > > Now start hiding all this stuff in VIEWs immediately and add an
[quoted text, click to view]
>> 1. What's to stop you putting extra information into the Sedans or SUV tables (like descriptions etc.) instead of creating separate tables?<< If you don't need further subclass breakdowns, then by all means stop at this level and get all the attributes in the table. In your case, organizations might have tax status codes which are different from individuals, so the Customers references the Organzations table and the Organzations table has a column for tax status which is not in the Individuals table. [quoted text, click to view] >> 2. Do you think it would be good to have primary keys that span two tables in order to get rid of the vehicles table? Would there be anydisadvantage to doing it this way instead of the way you outlined? << The reason for having a Vehicles table is to establish a class that is then broken down into disjoint sub-classses; this is the mechanism that assures a VIN belongs to SUV or Sedans but never both. What I am proposing is a bit complicated at first sight. You have a nested set (or whatever) model for the tree structure that might look like this: CREATE TABLE Heirarchy (vin CHAR(17) UNIQUE -- not null? default? REFERENCES Vehicles (vin) ON UPDATE CASCADE ON DELETE ??, -- need a rule lft INTEGER NOT NULL, rgt INTEGER NOT NULL, PRIMARY KEY (lft, rgt), <<more constraints -- see book>>); You now have to sit down and really think about the business rules for the Heirarchy. The nodes (vehicles) have their class hierarchy on that side of the RDBMS. You do joins from OrgChart (structure)-> Vehicles (node class) -> SUV or Sedans (node sub-class) to get your data. --CELKO-- =========================== Please post DDL, so that people do not have to guess what the keys, constraints, Declarative Referential Integrity, datatypes, etc. in your schema are. *** Sent via Devdex http://www.devdex.com ***
[quoted text, click to view]
> Separate the tree structure from the nodes. Ilike the nested sets > model for the structure, but you can pick whatever works best for your > situation. Then the nodes can go into another table. CELKO, Just wanted to double check: by "separating the nodes from the tree" do you mean doing this (using path enumeration model): nodes (id int, name varchar, ... etc) nodetree (path varchar, int nodeId) AS OPPOSED TO THIS: nodes (id int, name varchar, path varchar, ... etc) Thanks again! Jeff [quoted text, click to view] jcelko212@earthlink.net (--CELKO--) wrote in message news:<18c7b3c2.0407010727.4fbb407d@posting.google.com>...
> Here is the link on Amazon.com for my new book on "Trees & Hierarchies > in SQL" > > http://www.amazon.com/exec/obidos/tg/detail/-/1558609202/qid=1080772873/sr=1-1/ref=sr_1_1/102-7683601-6345721?v=glance&s=books#product-details > > Separate the tree structure from the nodes. Ilike the nested sets > model for the structure, but you can pick whatever works best for your > situation. Then the nodes can go into another table. > > The classic scenario calls for a root class with all the common > attributes and then specialized sub-classes under it. As an example, > let's take the class of Vehicles and find an industry standard > identifier (VIN), and add two mutually exclusive sub-classes, Sport > utility vehicles and sedans ('SUV', 'SED'). > > CREATE TABLE Vehicles > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) NOT NULL > CHECK(vehicle_type IN ('SUV', 'SED')), > UNIQUE (vin, vehicle_type), > ..); > > Notice the overlapping candidate keys. I then use a compound candidate > key (vin, vehicle_type) and a constraint in each sub-class table to > assure that the vehicle_type is locked and agrees with the Vehicles > table. Add some DRI actions and you are done: > > CREATE TABLE SUV > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT 'SUV' NOT NULL > CHECK(vehicle_type = 'SUV'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Vehicles(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > CREATE TABLE Sedans > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL > CHECK(vehicle_type = 'SED'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Vehicles(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > I can continue to build a hierarchy like this. For example, if I had > a Sedans table that broke down into two-door and four-door sedans, I > could a schema like this: > > CREATE TABLE Sedans > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL > CHECK(vehicle_type IN ('2DR', '4DR', 'SED')), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Vehicles(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > CREATE TABLE TwoDoor > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT '2DR' NOT NULL > CHECK(vehicle_type = '2DR'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Sedans(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > CREATE TABLE FourDoor > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT '4DR' NOT NULL > CHECK(vehicle_type = '4DR'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Sedans (vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > The idea is to build a chain of identifiers and types in a UNIQUE() > constraint that go up the tree when you use a REFERENCES constraint. > Obviously, you can do variants of this trick to get different class > structures. > > If an entity doesn't have to be exclusively one subtype, you play with > the root of the class hierarchy: > > CREATE TABLE Vehicles > (vin CHAR(17) NOT NULL, > vehicle_type CHAR(3) NOT NULL > CHECK(vehicle_type IN ('SUV', 'SED')), > PRIMARY KEY (vin, vehicle_type), > ..); > > Now start hiding all this stuff in VIEWs immediately and add an
[quoted text, click to view]
>> in reality I have about 12 entities with which both organizations and users can have relationships so I have to have 24 linktables. Nothing wrong with that per se but I just think it is inelegant. << Well, sometimes the model is complex. If those relationships are all different, then you need to have table for each relationship. [quoted text, click to view] >> I did not have high expectations because I thought it was just a quickie to capitalize on success of "SQL for smarties" but I waspleasantly surprised: as the title suggests, it is definitely the most comprehensive compilation of SQL techiques for modelling trees in relational structures all gathered in one place that I ever saw. << Thank you! Where were you when I needed jacket copy? --CELKO-- =========================== Please post DDL, so that people do not have to guess what the keys, constraints, Declarative Referential Integrity, datatypes, etc. in your schema are. *** Sent via Devdex http://www.devdex.com ***
[quoted text, click to view]
>> Just wanted to double check: by "separating the nodes from the tree" do you mean doing this (using path enumeration model): <<Where is the DDL? What you posted was useless on several levels. NEVER use something as vague as "id" for a column name. NEVER, NEVER, NEVER name a data element for its current location -- node_id always a node_id wherever it appears. This is fundamental data modeling -- name thing s for what they are in the logical model, not for how or where they are PHYSICALLY stored or how they are used in one place. I think that you might have meant this: CREATE TABLE Nodes (node_id INTEGER NOT NULL PRIMARY KEY, node_name CHAR(20) NOT NULL, ... ); CREATE TABLE Tree (node_id INTEGER NOT NULL REFERENCES Nodes (node_id) ON UPDATE CASCADE ON DELETE CASCADE, path VARCHAR(100) NOT NULL CHECK (<< valid path predicate >>), .. ); Now you need to decide how to handle DRI actions; I made a guess. And how you want to build the path string - letters, digits, fixed or
[quoted text, click to view]
--CELKO-- wrote: > Here is the link on Amazon.com for my new book on "Trees & Hierarchies > in SQL" > > http://www.amazon.com/exec/obidos/tg/detail/-/1558609202/qid=1080772873/sr=1-1/ref=sr_1_1/102-7683601-6345721?v=glance&s=books#product-details > > Separate the tree structure from the nodes. Ilike the nested sets > model for the structure, but you can pick whatever works best for your > situation. Then the nodes can go into another table. > > The classic scenario calls for a root class with all the common > attributes and then specialized sub-classes under it. As an example, > let's take the class of Vehicles and find an industry standard > identifier (VIN), and add two mutually exclusive sub-classes, Sport > utility vehicles and sedans ('SUV', 'SED'). > > CREATE TABLE Vehicles > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) NOT NULL > CHECK(vehicle_type IN ('SUV', 'SED')), > UNIQUE (vin, vehicle_type), > ..); > > Notice the overlapping candidate keys. I then use a compound candidate > key (vin, vehicle_type) and a constraint in each sub-class table to > assure that the vehicle_type is locked and agrees with the Vehicles > table. Add some DRI actions and you are done: > > CREATE TABLE SUV > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT 'SUV' NOT NULL > CHECK(vehicle_type = 'SUV'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Vehicles(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > CREATE TABLE Sedans > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL > CHECK(vehicle_type = 'SED'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Vehicles(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > I can continue to build a hierarchy like this. For example, if I had > a Sedans table that broke down into two-door and four-door sedans, I > could a schema like this: > > CREATE TABLE Sedans > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL > CHECK(vehicle_type IN ('2DR', '4DR', 'SED')), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Vehicles(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > CREATE TABLE TwoDoor > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT '2DR' NOT NULL > CHECK(vehicle_type = '2DR'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Sedans(vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > CREATE TABLE FourDoor > (vin CHAR(17) NOT NULL PRIMARY KEY, > vehicle_type CHAR(3) DEFAULT '4DR' NOT NULL > CHECK(vehicle_type = '4DR'), > UNIQUE (vin, vehicle_type), > FOREIGN KEY (vin, vehicle_type) > REFERENCES Sedans (vin, vehicle_type) > ON UPDATE CASCADE > ON DELETE CASCADE, > ..); > > The idea is to build a chain of identifiers and types in a UNIQUE() > constraint that go up the tree when you use a REFERENCES constraint. > Obviously, you can do variants of this trick to get different class > structures. > > If an entity doesn't have to be exclusively one subtype, you play with > the root of the class hierarchy: > > CREATE TABLE Vehicles > (vin CHAR(17) NOT NULL, > vehicle_type CHAR(3) NOT NULL > CHECK(vehicle_type IN ('SUV', 'SED')), > PRIMARY KEY (vin, vehicle_type), > ..); > > Now start hiding all this stuff in VIEWs immediately and add an > INSTEAD OF trigger to those VIEWs. Joe ... sorry ... but integrity demands that I write the following: We have a usenet group named comp.databases.oracle.marketplace specifically designated for promotions. In the future it would be appreciated if you posted book, or any other, promotions there. Thanks. For everyone else ... I recommend Joe's books to my students and highly recommend them. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)
[quoted text, click to view]
Marshall Spight wrote: > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1088831855.922891@yasure... > >>Joe ... sorry ... but integrity demands that I write the following: >> >>We have a usenet group named comp.databases.oracle.marketplace >>specifically designated for promotions. In the future it would be >>appreciated if you posted book, or any other, promotions there. > > > Uh, so a guy posts two lines with a link where you can buy his > book, and 100 lines of helping someone out with his question, > and you bust his balls for "promotions?" You also assume > that because the original poster included an oracle newsgroup > in one of the four newsgroups he posted to, that everyone responding > on any of those newsgroups should somehow know your local > culture and customs and adhere to them? > > You have a funny idea of integrity. > > > Marshall I don't show favoritism when it come to calling spam spam. Even when it is someone as esteemed as Joe Celko. But exactly what is it you have contributed to c.d.o.server? -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)
[quoted text, click to view]
"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1088831855.922891@yasure... > > Joe ... sorry ... but integrity demands that I write the following: > > We have a usenet group named comp.databases.oracle.marketplace > specifically designated for promotions. In the future it would be > appreciated if you posted book, or any other, promotions there. Uh, so a guy posts two lines with a link where you can buy his book, and 100 lines of helping someone out with his question, and you bust his balls for "promotions?" You also assume that because the original poster included an oracle newsgroup in one of the four newsgroups he posted to, that everyone responding on any of those newsgroups should somehow know your local culture and customs and adhere to them? You have a funny idea of integrity. Marshall
[quoted text, click to view]
Daniel Morgan <damorgan@x.washington.edu> wrote: >Marshall Spight wrote: > >> "Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1088831855.922891@yasure... >> >>>Joe ... sorry ... but integrity demands that I write the following: >>> >>>We have a usenet group named comp.databases.oracle.marketplace >>>specifically designated for promotions. In the future it would be >>>appreciated if you posted book, or any other, promotions there. >> Uh, so a guy posts two lines with a link where you can buy his >> book, and 100 lines of helping someone out with his question, >> and you bust his balls for "promotions?" You also assume >> that because the original poster included an oracle newsgroup >> in one of the four newsgroups he posted to, that everyone responding >> on any of those newsgroups should somehow know your local >> culture and customs and adhere to them? >> >> You have a funny idea of integrity. >I don't show favoritism when it come to calling spam spam. Even when it >is someone as esteemed as Joe Celko. What spam? OP asked for help, and Mr. Celko gave it. [quoted text, click to view] >But exactly what is it you have contributed to c.d.o.server? Possibly a reminder of priorities? You may have missed this point though. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases.
[quoted text, click to view]
Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1088831855.922891@yasure>... > --CELKO-- wrote: > > > Here is the link on Amazon.com for my new book on "Trees & Hierarchies > > in SQL" > > > > http://www.amazon.com/exec/obidos/tg/detail/-/1558609202/qid=1080772873/sr=1-1/ref=sr_1_1/102-7683601-6345721?v=glance&s=books#product-details > > > > Separate the tree structure from the nodes. Ilike the nested sets > > model for the structure, but you can pick whatever works best for your > > situation. Then the nodes can go into another table. > > > > The classic scenario calls for a root class with all the common > > attributes and then specialized sub-classes under it. As an example, > > let's take the class of Vehicles and find an industry standard > > identifier (VIN), and add two mutually exclusive sub-classes, Sport > > utility vehicles and sedans ('SUV', 'SED'). > > > > CREATE TABLE Vehicles > > (vin CHAR(17) NOT NULL PRIMARY KEY, > > vehicle_type CHAR(3) NOT NULL > > CHECK(vehicle_type IN ('SUV', 'SED')), > > UNIQUE (vin, vehicle_type), > > ..); > > > > Notice the overlapping candidate keys. I then use a compound candidate > > key (vin, vehicle_type) and a constraint in each sub-class table to > > assure that the vehicle_type is locked and agrees with the Vehicles > > table. Add some DRI actions and you are done: > > > > CREATE TABLE SUV > > (vin CHAR(17) NOT NULL PRIMARY KEY, > > vehicle_type CHAR(3) DEFAULT 'SUV' NOT NULL > > CHECK(vehicle_type = 'SUV'), > > UNIQUE (vin, vehicle_type), > > FOREIGN KEY (vin, vehicle_type) > > REFERENCES Vehicles(vin, vehicle_type) > > ON UPDATE CASCADE > > ON DELETE CASCADE, > > ..); > > > > CREATE TABLE Sedans > > (vin CHAR(17) NOT NULL PRIMARY KEY, > > vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL > > CHECK(vehicle_type = 'SED'), > > UNIQUE (vin, vehicle_type), > > FOREIGN KEY (vin, vehicle_type) > > REFERENCES Vehicles(vin, vehicle_type) > > ON UPDATE CASCADE > > ON DELETE CASCADE, > > ..); > > > > I can continue to build a hierarchy like this. For example, if I had > > a Sedans table that broke down into two-door and four-door sedans, I > > could a schema like this: > > > > CREATE TABLE Sedans > > (vin CHAR(17) NOT NULL PRIMARY KEY, > > vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL > > CHECK(vehicle_type IN ('2DR', '4DR', 'SED')), > > UNIQUE (vin, vehicle_type), > > FOREIGN KEY (vin, vehicle_type) > > REFERENCES Vehicles(vin, vehicle_type) > > ON UPDATE CASCADE > > ON DELETE CASCADE, > > ..); > > > > CREATE TABLE TwoDoor > > (vin CHAR(17) NOT NULL PRIMARY KEY, > > vehicle_type CHAR(3) DEFAULT '2DR' NOT NULL > > CHECK(vehicle_type = '2DR'), > > UNIQUE (vin, vehicle_type), > > FOREIGN KEY (vin, vehicle_type) > > REFERENCES Sedans(vin, vehicle_type) > > ON UPDATE CASCADE > > ON DELETE CASCADE, > > ..); > > > > CREATE TABLE FourDoor > > (vin CHAR(17) NOT NULL PRIMARY KEY, > > vehicle_type CHAR(3) DEFAULT '4DR' NOT NULL > > CHECK(vehicle_type = '4DR'), > > UNIQUE (vin, vehicle_type), > > FOREIGN KEY (vin, vehicle_type) > > REFERENCES Sedans (vin, vehicle_type) > > ON UPDATE CASCADE > > ON DELETE CASCADE, > > ..); > > > > The idea is to build a chain of identifiers and types in a UNIQUE() > > constraint that go up the tree when you use a REFERENCES constraint. > > Obviously, you can do variants of this trick to get different class > > structures. > > > > If an entity doesn't have to be exclusively one subtype, you play with > > the root of the class hierarchy: > > > > CREATE TABLE Vehicles > > (vin CHAR(17) NOT NULL, > > vehicle_type CHAR(3) NOT NULL > > CHECK(vehicle_type IN ('SUV', 'SED')), > > PRIMARY KEY (vin, vehicle_type), > > ..); > > > > Now start hiding all this stuff in VIEWs immediately and add an > > INSTEAD OF trigger to those VIEWs. > > Joe ... sorry ... but integrity demands that I write the following: > > We have a usenet group named comp.databases.oracle.marketplace > specifically designated for promotions. In the future it would be > appreciated if you posted book, or any other, promotions there. > > Thanks. > > For everyone else ... I recommend Joe's books to my students and > highly recommend them. Daniel Morgan: Cannot you just shut the ffff up? Take your contributions and shove it! This an international newsgroup and it NOT yours to guard. The charter of this newsgroup is clear and does not allow you to add shameless lines of advertisements while denying others! So shut up! you can create your own newsgroup where you can control things --- you crazy control freak. Watch the movie "Tow Truck" to see what you look like. Obviously you are downgrading this group and many others to your level of integrity which you completely lack. Remember, you big jumble of Q that Oracle itself is a product! and you have no rights what so ever to determine what is good; and what is like you of what you don't like. You get it?! Read Simon's peom! Or download OMLET and run it and you would get random lines of insults and images geared specifically to YOU! Till 2010. Now what?!
[quoted text, click to view]
Noons wrote: > > forwarded to abuse. > I have too as have a number of my students. Here's what we have found: Pinging omlet.org returns 66.218.79.158 which in return, when pinged, returns p2w2.geo.scd.yahoo.com. Complaints have been filed with: abuse@yahoo.com groups-abuse@google.com I encourage others to do so too and and in case anyone wonders who this spam-troll really is ... Domain Name:OMLET.ORG Created On:15-Jun-2004 10:54:38 UTC ... (been in business only 2 weeks) Sponsoring Registrar:R52-LROR Registrant Name:Amjad Daoud Registrant Street1:Queen Noor Br 07 Registrant City:Amman Registrant State/Province:Amman Registrant Postal Code:9626 Registrant Country:JO ... (this is the country of Jordan) Registrant Phone:+1.96265163864 Registrant Email:teraknowledgesystems@yahoo.com Yes our troll lives in the country of Jordan. You can purchase a product from someone to use with your valuable Oracle database where there is not only no company behind it there is just one guy in a third-world country. Please address complaints about his spamming and abuse to: Tech Name:YahooDomains TechContact Tech Organization:Yahoo! Inc Tech Street1:701 First Ave. Tech City:Sunnyvale Tech State/Province:CA Tech Postal Code:94089 Tech Country:US Tech Phone:+1.619-881-3096 Tech Email:domain.tech@YAHOO-INC.COM Name Server:YNS1.YAHOO.COM Name Server:YNS2.YAHOO.COM Thank you. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)
omlet@omlet.org apparently said,on my timestamp of 5/07/2004 8:27 AM:
[quoted text, click to view] > > > Daniel Morgan: Cannot you just shut the ffff up? Take your > contributions and shove it! This an international newsgroup and it NOT > yours to guard. The charter of this newsgroup is clear and does not > allow you to add shameless lines of advertisements while denying > others! > > So shut up! you can create your own newsgroup where you can control > things --- you crazy control freak. Watch the movie "Tow Truck" to see > what you look like. > > Obviously you are downgrading this group and many others to your level > of integrity which you completely lack. > > Remember, you big jumble of Q that Oracle itself is a product! and you > have no rights what so ever to determine what is good; and what is > like you of what you don't like. You get it?! Read Simon's peom! Or > download OMLET and run it and you would get random lines of insults > and images geared specifically to YOU! Till 2010. > > Now what?! > Right on your tail. forwarded to abuse. -- Cheers Nuno Souto
**** Post for FREE via your newsreader at post.usenet.com ****
[quoted text, click to view] "Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1089057907.319050@yasure... > Here's what we have found: > I encourage others to do so too and and in case anyone wonders who this > spam-troll really is ... > Domain Name:OMLET.ORG > Created On:15-Jun-2004 10:54:38 UTC ... (been in business only 2 weeks) > Sponsoring Registrar:R52-LROR > Registrant Name:Amjad Daoud > Registrant Street1:Queen Noor Br 07 > Registrant City:Amman > Registrant State/Province:Amman > Registrant Postal Code:9626 > Registrant Country:JO ... (this is the country of Jordan) > Registrant Phone:+1.96265163864 > Registrant Email:teraknowledgesystems@yahoo.com > Yes our troll lives in the country of Jordan. You can purchase a > product from someone to use with your valuable Oracle database > where there is not only no company behind it there is just one > guy in a third-world country. You need to be more careful about this kind of language. One of Amjad Daoud signatures I found on the web is: Amjad Daoud The OMLET Team Lead Tera Knowledge Systems, Inc. Arlington, Texas <--------------- This is not Jordan Besides: What do you have against "guys from third-world countries" ? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
[quoted text, click to view]
"Marshall Spight" <mspight@dnai.com> wrote in message news:8KNFc.20603$%_6.12831@attbi_s01... > ...Trees and > Hierarchies in SQL doesn't have the same cachet as the latest > work by David Sedaris. In fact, it's Amazon's 16,754's most > popular item, right behind the $350 "Suunto Yachtsman Wristop > Computer Watch w/ Barometer and Compass... How did you query this? Does amazon provides SQL interface nowadays? select book.* from books where rank between 15000 and 16000 ???
[quoted text, click to view]
"x" <x-false@yahoo.com> wrote in message news:<40ea4378@post.usenet.com>... He doesn't. Daniel, I and others have just been dealing with this> **** Post for FREE via your newsreader at post.usenet.com **** > > > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > news:1089057907.319050@yasure... > > Here's what we have found: > > > I encourage others to do so too and and in case anyone wonders who this > > spam-troll really is ... > > > Domain Name:OMLET.ORG > > Created On:15-Jun-2004 10:54:38 UTC ... (been in business only 2 weeks) > > Sponsoring Registrar:R52-LROR > > Registrant Name:Amjad Daoud > > Registrant Street1:Queen Noor Br 07 > > Registrant City:Amman > > Registrant State/Province:Amman > > Registrant Postal Code:9626 > > Registrant Country:JO ... (this is the country of Jordan) > > Registrant Phone:+1.96265163864 > > Registrant Email:teraknowledgesystems@yahoo.com > > > Yes our troll lives in the country of Jordan. You can purchase a > > product from someone to use with your valuable Oracle database > > where there is not only no company behind it there is just one > > guy in a third-world country. > > You need to be more careful about this kind of language. > One of Amjad Daoud signatures I found on the web is: > > Amjad Daoud > The OMLET Team Lead > Tera Knowledge Systems, Inc. > Arlington, Texas <--------------- This is not Jordan > > Besides: What do you have against "guys from third-world countries" ? > > troll in the ORACLE groups for a while now. And you should note that you presented the company address, which may be only a sales office and not the location of the "OMLET Team". It certainly is different from the residence of this guy. Calling Amjad a troll is certainly MUCH more polite than the crap he
[quoted text, click to view]
"x" <x-false@yahoo.com> wrote in message news:<40ea4378@post.usenet.com>... > **** Post for FREE via your newsreader at post.usenet.com **** > > > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > news:1089057907.319050@yasure... > > Here's what we have found: > > > I encourage others to do so too and and in case anyone wonders who this > > spam-troll really is ... > > > Domain Name:OMLET.ORG > > Created On:15-Jun-2004 10:54:38 UTC ... (been in business only 2 weeks) > > Sponsoring Registrar:R52-LROR > > Registrant Name:Amjad Daoud > > Registrant Street1:Queen Noor Br 07 > > Registrant City:Amman > > Registrant State/Province:Amman > > Registrant Postal Code:9626 > > Registrant Country:JO ... (this is the country of Jordan) > > Registrant Phone:+1.96265163864 > > Registrant Email:teraknowledgesystems@yahoo.com > > > Yes our troll lives in the country of Jordan. You can purchase a > > product from someone to use with your valuable Oracle database > > where there is not only no company behind it there is just one > > guy in a third-world country. > > You need to be more careful about this kind of language. > One of Amjad Daoud signatures I found on the web is: > > Amjad Daoud > The OMLET Team Lead > Tera Knowledge Systems, Inc. > Arlington, Texas <--------------- This is not Jordan But check out eggy-weggies email, it's Jordanian. Not that that means anything, I certainly am not in Tonga or oz as some of my web presence may imply. But he says Sunnyvale, and Texas, and the registration is on Queen Noor's... something. All-in-all, not a situation a rational person would want to take advice or a product from. And wassup with the 619 area code on the Sunnyvale provider, a cell? [quoted text, click to view] > > Besides: What do you have against "guys from third-world countries" ? There are matters of security, economics, legal liability and trust involved. But besides that, rotten egg seems to have gone well into net-psychoses, cyberstalking anyone who he perceives as attacking him, which is pretty much anyone acknowledging his existence. Not a pretty sight. DM has once again made a fast, correct call about a spammer. As far as celko, I thought DM was suitably polite in explaining the plug issue. It was a minor gaffe on celko's part, perfectly understandable, DM didn't "break his balls." I would say DM should have ignored it giving the crossposting, but he clearly is making an effort to be fair and non-partisan when netcopping. My bias is towards letting people plug their work amid a useful answer, but DM has almost convinced me his way is better. jg -- @home.com is bogus. Internet meltdown, news at 11:
[quoted text, click to view]
jlanfield2003@yahoo.com (Jeff Lanfield) wrote: >As the original poster I would agree here. If it is solicited and >relevant to the question asked it's not spam. I actually did end up >buying Mr. Celko's book and can attest that it is quite useful for >solving the class of problems I was interested in. > >While in general people should not post ads for books they wrote on >tech newsgroups an exception should definitely be made for cases like >this one where the book contains pretty much the exact answer. Exactly. I am glad you got the help you needed. That is a large part of what technical newsgroups are for. [snip] Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases.
[quoted text, click to view]
"Mikito Harakiri" <mikharakiri@iahu.com> wrote in message news:wIAGc.12$ZJ2.250@news.oracle.com... > "Marshall Spight" <mspight@dnai.com> wrote in message > news:8KNFc.20603$%_6.12831@attbi_s01... > > ...Trees and > > Hierarchies in SQL doesn't have the same cachet as the latest > > work by David Sedaris. In fact, it's Amazon's 16,754's most > > popular item, right behind the $350 "Suunto Yachtsman Wristop > > Computer Watch w/ Barometer and Compass... > > How did you query this? Does amazon provides SQL interface nowadays? Methodology: Click on the link provided by Mr. Celko. Scroll down to the "product details" section. Read the sales rank there (note that it's changed since then.) --> "Amazon.com sales rank: 16,754" subtract one :-) --> 16,753 Go to www.google.com search exactly as follows: site:amazon.com "sales rank: 16753" Click on the link Often when a site doesn't provide some bit of info directly, there's a way to get to it with judicious use of google features. For example, if you want to know if a given 32 bit number is prime, often times the fastest way to decide is to google for it. If it's prime, it'll be on some indexed page of prime numbers somewhere. Marshall
[quoted text, click to view]
"Marshall Spight" <mspight@dnai.com> wrote in message news:8KIGc.34726$a24.6231@attbi_s03... > Methodology: > > Click on the link provided by Mr. Celko. > Scroll down to the "product details" section. > Read the sales rank there (note that it's changed since then.) > --> "Amazon.com sales rank: 16,754" > subtract one :-) > --> 16,753 > Go to www.google.com > search exactly as follows: > site:amazon.com "sales rank: 16753" > Click on the link > > Often when a site doesn't provide some bit of > info directly, there's a way to get to it with > judicious use of google features. > > For example, if you want to know if a given > 32 bit number is prime, often times the fastest > way to decide is to google for it. If it's prime, > it'll be on some indexed page of prime numbers > somewhere. Very clever. Now, I wouldn't be surprised if you invent how to do aggregation and joins via google.
**** Post for FREE via your newsreader at post.usenet.com ****
[quoted text, click to view] "Ed prochak" <ed.prochak@magicinterface.com> wrote in message news:4b5394b2.0407061035.3fac9628@posting.google.com... > "x" <x-false@yahoo.com> wrote in message news:<40ea4378@post.usenet.com>... > > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message > > news:1089057907.319050@yasure... > > > Here's what we have found: > > > I encourage others to do so too and and in case anyone wonders who this > > > spam-troll really is ... > > > Domain Name:OMLET.ORG > > > Created On:15-Jun-2004 10:54:38 UTC ... (been in business only 2 weeks) > > > Sponsoring Registrar:R52-LROR > > > Registrant Name:Amjad Daoud > > > Registrant Street1:Queen Noor Br 07 > > > Registrant City:Amman > > > Registrant State/Province:Amman > > > Registrant Postal Code:9626 > > > Registrant Country:JO ... (this is the country of Jordan) > > > Registrant Phone:+1.96265163864 > > > Registrant Email:teraknowledgesystems@yahoo.com > > > Yes our troll lives in the country of Jordan. You can purchase a > > > product from someone to use with your valuable Oracle database > > > where there is not only no company behind it there is just one > > > guy in a third-world country. > > You need to be more careful about this kind of language. > > One of Amjad Daoud signatures I found on the web is: > > Amjad Daoud > > The OMLET Team Lead > > Tera Knowledge Systems, Inc. > > Arlington, Texas <--------------- This is not Jordan > > Besides: What do you have against "guys from third-world countries" ? [quoted text, click to view] > He doesn't. Ok. My mistake. English is not my native tongue. :-)[quoted text, click to view] >Daniel, I and others have just been dealing with this > troll in the ORACLE groups for a while now. I didn't knew that. [quoted text, click to view] >And you should note that > you presented the company address, which may be only a sales office > and not the location of the "OMLET Team". It certainly is different > from the residence of this guy. I don't know if there is a company or a sale office there. But the address is from 2001 and looks like a company address from U.S.A. If one does business with a U.S.A. company, I think the U.S.A. and international laws apply. It is not relevant that the "OMLET Team" is just one guy from the country of Jordan, regardless if this country is a "third world country" or not. [quoted text, click to view] > Calling Amjad a troll is certainly MUCH more polite than the crap he > has spewed in the ORACLE groups. Probably he has done that when provoked. Calling Jordan a third world country has nothing to do with what Amjad has done. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
**** Post for FREE via your newsreader at post.usenet.com ****
[quoted text, click to view] "Joel Garry" <joel-garry@home.com> wrote in message news:91884734.0407061442.5a606c44@posting.google.com... > But check out eggy-weggies email, it's Jordanian. Not that that means > anything, I certainly am not in Tonga or oz as some of my web presence > may imply. But he says Sunnyvale, and Texas, and the registration is > on Queen Noor's... something. All-in-all, not a situation a rational > person would want to take advice or a product from. And wassup with > the 619 area code on the Sunnyvale provider, a cell? Exactly. It doesn't mean anything. If you want to pay him, then you may ask for a company address and warranties. [quoted text, click to view] > > Besides: What do you have against "guys from third-world countries" ? > There are matters of security, economics, legal liability and trust > involved. This matters are involved anyway. [quoted text, click to view] > But besides that, rotten egg seems to have gone well into > net-psychoses, cyberstalking anyone who he perceives as attacking him, > which is pretty much anyone acknowledging his existence. Not a pretty > sight. DM has once again made a fast, correct call about a spammer. You could show him some compassion then. [quoted text, click to view] > As far as celko, I thought DM was suitably polite in explaining the > plug issue. It was a minor gaffe on celko's part, perfectly > understandable, DM didn't "break his balls." I would say DM should > have ignored it giving the crossposting, but he clearly is making an > effort to be fair and non-partisan when netcopping. My bias is > towards letting people plug their work amid a useful answer, but DM > has almost convinced me his way is better. Every newsgroup has his trolls :-) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
[quoted text, click to view]
"x" <x-false@yahoo.com> wrote in message news:<40eba4a3$1@post.usenet.com>... > **** Post for FREE via your newsreader at post.usenet.com **** > > > "Joel Garry" <joel-garry@home.com> wrote in message > news:91884734.0407061442.5a606c44@posting.google.com... > > > But check out eggy-weggies email, it's Jordanian. Not that that means > > anything, I certainly am not in Tonga or oz as some of my web presence > > may imply. But he says Sunnyvale, and Texas, and the registration is > > on Queen Noor's... something. All-in-all, not a situation a rational > > person would want to take advice or a product from. And wassup with > > the 619 area code on the Sunnyvale provider, a cell? > > Exactly. It doesn't mean anything. > If you want to pay him, then you may ask for a company address and > warranties. What I want is for him to stop spamming this group. How might that happen? [quoted text, click to view] > > > > Besides: What do you have against "guys from third-world countries" ? > > > There are matters of security, economics, legal liability and trust > > involved. > > This matters are involved anyway. They are more involved when third-world countries are mixed in. I deal with many issues daily, living near one. There is a huge cultural issue, too, especially having to do with dealing with government regulations and legalities. [quoted text, click to view] > > > But besides that, rotten egg seems to have gone well into > > net-psychoses, cyberstalking anyone who he perceives as attacking him, > > which is pretty much anyone acknowledging his existence. Not a pretty > > sight. DM has once again made a fast, correct call about a spammer. > > You could show him some compassion then. My wife's job is to show compassion. But she doesn't post on usenet. In any unmoderated usenet group, there needs to be feedback and some consensus about what is appropriate for the group. This group has long taken a fairly strict no-spam stance, including creating an appropriate group for marketing. The reason for this stance comes from the experience of longtime posters who have seen groups get wiped out from not taking such a strict stance. Another aspect of this group is that it takes a critical view of postings - this is a good thing, dba work must be precise and correct or it is bad dba work. I think more compassion could be shown newbies, directing them towards proper research and docs, as opposed to harsh criticism, but that's just me, and I try to convince others of that by example rather than argument. Unfortunately, it doesn't seem to work as well as DM's way with newbie spammers. net.kooks do not need compassion, in fact, that may be just the wrong thing to do, since any iota of possibility that what they are doing isn't wrong will be rationalized into justification. [quoted text, click to view] > > > As far as celko, I thought DM was suitably polite in explaining the > > plug issue. It was a minor gaffe on celko's part, perfectly > > understandable, DM didn't "break his balls." I would say DM should > > have ignored it giving the crossposting, but he clearly is making an > > effort to be fair and non-partisan when netcopping. My bias is > > towards letting people plug their work amid a useful answer, but DM > > has almost convinced me his way is better. > > Every newsgroup has his trolls :-) > I don't think DM has any trolls eggy-weggy, or x-false, or whomever you might be today. jg -- @home.com is bogus.
Don't see what you're looking for? Try a search.
|
January 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
| home · blog · groups | Questions? Comments? Contact the dn |