## alzabo-general — Anything about Alzabo

You can subscribe to this list here.

 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 Jan Feb Mar Apr May Jun Jul (8) Aug (2) Sep (3) Oct (3) Nov Dec Jan (2) Feb (18) Mar (33) Apr (7) May (1) Jun (15) Jul (23) Aug (2) Sep (7) Oct (31) Nov (15) Dec (28) Jan (36) Feb (10) Mar (31) Apr (28) May (36) Jun (38) Jul (20) Aug (28) Sep (11) Oct (8) Nov (4) Dec (9) Jan (6) Feb (23) Mar (14) Apr (149) May (75) Jun (28) Jul (69) Aug (19) Sep (38) Oct (49) Nov (10) Dec (18) Jan (20) Feb (41) Mar (6) Apr (13) May (22) Jun (24) Jul (1) Aug (16) Sep (27) Oct (22) Nov (44) Dec (23) Jan (10) Feb (5) Mar (22) Apr (28) May (18) Jun (4) Jul (5) Aug (8) Sep (4) Oct (14) Nov (4) Dec Jan (2) Feb Mar (2) Apr (8) May (2) Jun (2) Jul (5) Aug (2) Sep Oct Nov (3) Dec Jan (1) Feb Mar (2) Apr (1) May Jun Jul (4) Aug (2) Sep Oct Nov (1) Dec Jan Feb (3) Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr (1) May Jun Jul Aug Sep Oct Nov Dec
S M T W T F S

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17
(18)
18
(16)
19

20
(1)
21
(9)
22
(13)
23
(2)
24
(2)
25

26

27

28

29

30

31
(8)

Showing 9 results of 9

 Re: [Alzabo] Patches From: Dave Rolsky - 2003-07-21 22:59:51 ```On Mon, 21 Jul 2003, Ken Williams wrote: > > But what about 1-to-1 relationships? What is the directionality there? > > As I've said before, directionality and cardinality are not the same. > They're orthogonal properties of a FK relationship. > > In my example I pasted from the paper, suppose the company only ever > accepted 1 order from each customer (perhaps the company's product > kills the customer or something). Then the cardinality is 1-to-1 but > the directionality between a customer and an order doesn't change. Ok, then this is the notion of dependency. An order is dependent on the customer. All orders must have a corresponding customer. Of course, it's possible have a relationship between two tables where both are independent. > I just don't see how a FK relationship should be symmetric or arbitrary > in direction. *None* of my foreign key relationships would work if I > reversed the direction of them. > > My idea of FKs is that they defines a relationship between columns, > where the set of values at one end of the FK defines the set of values > that may appear at the other end. That's just not a symmetric concept. If you have two tables with a 1-to-1 relationship, where neither is dependent, then what's the directionality? It's arbitrary, and entirely reversable. But that's a perfectly valid relationship between the two tables. -dave /*======================= House Absolute Consulting http://www.houseabsolute.com =======================*/ ```
 Re: [Alzabo] Patches From: Ken Williams - 2003-07-21 22:52:39 ```On Monday, July 21, 2003, at 05:09 PM, Dave Rolsky wrote: > > But what about 1-to-1 relationships? What is the directionality there? As I've said before, directionality and cardinality are not the same. They're orthogonal properties of a FK relationship. In my example I pasted from the paper, suppose the company only ever accepted 1 order from each customer (perhaps the company's product kills the customer or something). Then the cardinality is 1-to-1 but the directionality between a customer and an order doesn't change. > Often, it's entirely arbitrary. > I just don't see how a FK relationship should be symmetric or arbitrary in direction. *None* of my foreign key relationships would work if I reversed the direction of them. My idea of FKs is that they defines a relationship between columns, where the set of values at one end of the FK defines the set of values that may appear at the other end. That's just not a symmetric concept. -Ken ```
 Re: [Alzabo] Patches From: Dave Rolsky - 2003-07-21 22:10:32 ```On Mon, 21 Jul 2003, Ken Williams wrote: > > Do you have any references in the literature for this being canonical > > and well-accepted? > > Something tells me that no matter what I cite, it's not going to be > literature from the proper camp according to your database ideals, but > here goes nothing: Well, it would be ideal if it came from literature on relational theory, at least ;) > The CASE environment supports two types of relationships, or links, > between MDTUs. These relationships are termed master-detail and look-up, > which are terms that are commonly used by practitioners using different > 4GL environments. Both master-detail and look-up relationships are only > specified if a foreign key exists between the database tables on which > the MDTUs are based. For example, a =93masterdetail=94 relationship exist= s > between the INVOICES and ITEMS MDTUs in Figure 2 (note the placement of > the former MDTU being above the latter). This relationship implies that > a foreign key exists between the ITEMS and INVOICES database tables. > > Similarly, a =93look-up=94 relationship, such as the one between the > CUSTOMERS and INVOICE MDTUs in Figure 2, can only be defined if a > foreign key exists between the INVOICES and CUSTOMERS database tables. > Look-ups are positioned to the right of the referenced MDTU on the > diagram. > > ---------------------------------------------- > > I believe that you're saying that all FK relationships ought to be > "master-detail" relationships, whereas I'm saying I need to use > "look-up" relationships as well. This definition of directionality is based exclusively on the notion of how SQL defines foreign keys, which is what I've been saying is not right in the first place. I'm saying that either type of relationship is fine, but that you don't determine what type it is by looking at the SQL! In both of the cases in your quote, the relationships are 1-to-many. In 1-to-many relationships, it's generally the "many" which are dependent on the one. For example, "order items" depend on an "order". In this case, _you_ would probably say the relationship is "from order items to order". But what about 1-to-1 relationships? What is the directionality there? Often, it's entirely arbitrary. So, absent a logical definition of directionality that can be determined from the existing foreign key properties Alzabo defines, I don't see how we can have a "referenced_column" method. Now, if you just want a method that takes a column and finds the related column(s) in one or more other tables, that would be fine with me. -dave /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D House Absolute Consulting http://www.houseabsolute.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/ ```
 Re: [Alzabo] Patches From: Ken Williams - 2003-07-21 20:20:06 ```On Monday, July 21, 2003, at 10:34 AM, Dave Rolsky wrote: > On Mon, 21 Jul 2003, Ken Williams wrote: > >> I disagree on several points: >> >> 1) It's not just postgres, it's any database that supports FKs that >> I've come across. > > All of which are SQL databases. SQL is notoriously non-relational. > >> 2) What would it *mean* to declare a FK as somehow non-directional? >> That the data in the involved columns are somehow overlapping in some >> unspecified way? Awfully weird. The logic of foreign keys is that=20= >> one >> end is definitional and the other end is referential. That's=20 >> canonical >> and well-accepted. > > Do you have any references in the literature for this being canonical=20= > and > well-accepted? Something tells me that no matter what I cite, it's not going to be=20 literature from the proper camp according to your database ideals, but=20= here goes nothing: =46rom "Automated Reverse Engineering of Legacy 4GL Information System=20= Applications using the ITOC Workbench", John V. Harrison, Wie Ming=20 LimConference on Advanced Information Systems Engineering. http://citeseer.nj.nec.com/48704.html ---------------------------------------------- excerpt: The CASE environment supports two types of relationships, or links,=20 between MDTUs. These relationships are termed master-detail and look-up, which=20= are terms that are commonly used by practitioners using different 4GL=20 environments. Both master-detail and look-up relationships are only specified if a foreign=20= key exists between the database tables on which the MDTUs are based. For example,=20= a =93masterdetail=94 relationship exists between the INVOICES and ITEMS MDTUs in Figure 2 (note the placement of the former MDTU being above the latter). This=20 relationship implies that a foreign key exists between the ITEMS and INVOICES=20 database tables. Similarly, a =93look-up=94 relationship, such as the one between the=20 CUSTOMERS and INVOICE MDTUs in Figure 2, can only be defined if a foreign key=20 exists between the INVOICES and CUSTOMERS database tables. Look-ups are=20 positioned to the right of the referenced MDTU on the diagram. ---------------------------------------------- I believe that you're saying that all FK relationships ought to be=20 "master-detail" relationships, whereas I'm saying I need to use=20 "look-up" relationships as well. -Ken ```
 Re: [Alzabo] Patches From: Dave Rolsky - 2003-07-21 15:35:30 ```On Mon, 21 Jul 2003, Ken Williams wrote: > I disagree on several points: > > 1) It's not just postgres, it's any database that supports FKs that > I've come across. All of which are SQL databases. SQL is notoriously non-relational. > 2) What would it *mean* to declare a FK as somehow non-directional? > That the data in the involved columns are somehow overlapping in some > unspecified way? Awfully weird. The logic of foreign keys is that one > end is definitional and the other end is referential. That's canonical > and well-accepted. Do you have any references in the literature for this being canonical and well-accepted? > 2a) With a non-directional FK, how would you ever insert anything into > either table unless you could do it simultaneously in the two tables > (which wouldn't scale real well when multiple FKs are present)? Actually, if you read CJ Date's stuff, he explicitly talks about doing multiple operations in the same transaction in order to satisfy these sorts of dependencies. So we'd do ... INSERT INTO TABLE Foo, INSERT INTO TABLE Bar; Note the comma on the first line. Constraint checks would be done at the end of the whole statement (the semi-colon) and the whole thing would be rolled back if it failed. > The notion *I* don't buy is that the way all common databases implement > FKs is somehow non-standard and non-useful. I didn't say it wasn't useful, and it may be standardized, but that doesn't make it relational or correct. > > Nonetheless, that's why Alzabo implements adding a foreign key via the > > schema object, and I'd really like to move the "get" methods related to > > foreign keys into the schema object, at least in part. > > I'd expect an explosion in the complexity of the code, then. No, actually, it'd be simpler. Instead of storing FK objects in both tables, I'd just store one relationship object in the schema. -dave /*======================= House Absolute Consulting http://www.houseabsolute.com =======================*/ ```
 Re: [Alzabo] Patches From: Ken Williams - 2003-07-21 14:10:53 ```On Sunday, July 20, 2003, at 09:01 PM, Dave Rolsky wrote: > On Sun, 20 Jul 2003, Ken Williams wrote: > >> I know it can be *involved* in multiple relationships. But it can >> only >> *reference* one other column. Just like each person can be involved >> in >> lots of different parent/child relationships, but (modern variations >> notwithstanding) every person just has one mother. >> >> Or are you saying that a column can be a foreign key pointing to more >> than one foreign table? I've never seen a database that can do that, >> and besides, that's *way* weirder than anything you think *I'm* trying >> to do! ;-) > > I just don't buy this notion that foreign keys have some sort of > inherent > directionality at the _logical_ level. They certainly do - one end of the FK is always definitional, and the other end is referential. Without that, the whole notion of FKs falls apart. > Yes, Postgres may force you > declare foreign key _constraints_ in a specify way, in just one table, > but > that has nothing to do with the logical level, it's just an > implementation > detail. I disagree on several points: 1) It's not just postgres, it's any database that supports FKs that I've come across. 2) What would it *mean* to declare a FK as somehow non-directional? That the data in the involved columns are somehow overlapping in some unspecified way? Awfully weird. The logic of foreign keys is that one end is definitional and the other end is referential. That's canonical and well-accepted. 2a) With a non-directional FK, how would you ever insert anything into either table unless you could do it simultaneously in the two tables (which wouldn't scale real well when multiple FKs are present)? The notion *I* don't buy is that the way all common databases implement FKs is somehow non-standard and non-useful. > Nonetheless, that's why Alzabo implements adding a foreign key via the > schema object, and I'd really like to move the "get" methods related to > foreign keys into the schema object, at least in part. I'd expect an explosion in the complexity of the code, then. -Ken ```
 Re: [Alzabo] Patches From: Dave Rolsky - 2003-07-21 02:02:23 ```On Sun, 20 Jul 2003, Ken Williams wrote: > >> No, a foreign key column always references exactly one other column. > > > > No, a column can be involved in multiple relationships. Columns are > > polyamorous by nature ;) > > I know it can be *involved* in multiple relationships. But it can only > *reference* one other column. Just like each person can be involved in > lots of different parent/child relationships, but (modern variations > notwithstanding) every person just has one mother. > > Or are you saying that a column can be a foreign key pointing to more > than one foreign table? I've never seen a database that can do that, > and besides, that's *way* weirder than anything you think *I'm* trying > to do! ;-) I just don't buy this notion that foreign keys have some sort of inherent directionality at the _logical_ level. Yes, Postgres may force you declare foreign key _constraints_ in a specify way, in just one table, but that has nothing to do with the logical level, it's just an implementation detail. A relationship is between tables, and the columns in those tables. As such, it'd be better if they were defined as _schema_ constraints, not table constraints. Of course, I don't know of any RDBMS's that support schema constraints ;) Nonetheless, that's why Alzabo implements adding a foreign key via the schema object, and I'd really like to move the "get" methods related to foreign keys into the schema object, at least in part. > >> Hmm, I'll look into that. I don't think that explains everything, but > >> maybe it's part of the picture. I never really wrapped my mind around > >> this problem in the first place. > > > > It fixed it for me locally. > > I'm not sure I ever wrote a proper test for it though, so let me make > sure I can do that (or that I already did?). The test for reverse engineering a serial column effectively tests this as well, in 12_rev_engineer_pk.t -dave /*======================= House Absolute Consulting http://www.houseabsolute.com =======================*/ ```
 Re: [Alzabo] Patches From: Ken Williams - 2003-07-21 01:51:45 ```On Sunday, July 20, 2003, at 08:11 PM, Dave Rolsky wrote: > On Sun, 20 Jul 2003, Ken Williams wrote: >>> Based on our recent discussion, I don't think this does anything that >>> makes sense to me. Even by your definition of how this should work, >>> it's >>> theoretically possible that their could be more than one column that >>> is >>> being referenced, right? >> >> No, a foreign key column always references exactly one other column. > > No, a column can be involved in multiple relationships. Columns are > polyamorous by nature ;) I know it can be *involved* in multiple relationships. But it can only *reference* one other column. Just like each person can be involved in lots of different parent/child relationships, but (modern variations notwithstanding) every person just has one mother. Or are you saying that a column can be a foreign key pointing to more than one foreign table? I've never seen a database that can do that, and besides, that's *way* weirder than anything you think *I'm* trying to do! ;-) >>> I think the problem is actually that identifiers >>> can now be 63 chars long in Pg 7.3, versus 31 in previous versions. >>> I >>> think I Josh Jore reported some problem related to this. >> >> Hmm, I'll look into that. I don't think that explains everything, but >> maybe it's part of the picture. I never really wrapped my mind around >> this problem in the first place. > > It fixed it for me locally. I'm not sure I ever wrote a proper test for it though, so let me make sure I can do that (or that I already did?). -Ken ```
 Re: [Alzabo] Patches From: Dave Rolsky - 2003-07-21 01:12:17 ```On Sun, 20 Jul 2003, Ken Williams wrote: > >> * lib/Alzabo/Column.pm: adds a referenced_column() method, with docs. > >> Tests are included for it later in the patch, in t/02-create.t and > >> t/12-rev_engineer_pg_fk.t . > > > > Based on our recent discussion, I don't think this does anything that > > makes sense to me. Even by your definition of how this should work, > > it's > > theoretically possible that their could be more than one column that is > > being referenced, right? > > No, a foreign key column always references exactly one other column. No, a column can be involved in multiple relationships. Columns are polyamorous by nature ;) > >> * lib/Alzabo/Driver/PostgreSQL.pm: serial detection wasn't working > >> properly for me, but I'm not at all confident that this is the right > >> solution for other versions of Postgres. This is the one part of my > >> patch that I don't consider well-tested. > > > > That doesn't seem right. I think the problem is actually that > > identifiers > > can now be 63 chars long in Pg 7.3, versus 31 in previous versions. I > > think I Josh Jore reported some problem related to this. > > Hmm, I'll look into that. I don't think that explains everything, but > maybe it's part of the picture. I never really wrapped my mind around > this problem in the first place. It fixed it for me locally. -dave /*======================= House Absolute Consulting http://www.houseabsolute.com =======================*/ ```

Showing 9 results of 9