 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / General DB Topics / DB Theory / September 2005Indexes and Logical design
A little while ago, I remarked that I reluctantly included indexes in the logical design, and Marshall asked why. There's a great case to be made against including indexes in the logical design, and I suspect Marshall can make that case better than I can. Let me tell you why I lean the other way. It's more a matter of several little reasons than one big one. Before I start, after thinking it over, I've decided that it's more precise to say that indexes and tables (in an SQL implementation) are not the logical model as such. They are the reflection of the logical model in the implementation. Second, tables and indexes have physical features as well as logical features. In at least the Oracle dialect of SQL, its separated out as follows: create table FUBAR (logical features) physical features; create index FUBAR_IDX on table FUBAR (logical features) physical features; Now, here are my reasons: First, Data Architect divides objects into "schema objects" and "database objects". Tables and indexes are both included with the schema objects, along with views, procedures, and other stuff. Database objects are things like tablespaces, that have no counterpart in the logical model. Second, programmers always expect to see the indexes in the logical design. They should really need to see them, but they have a felt need. I'm philosophical about it. If we're going to take away the pointers they love to play with, we'd better throw them a bone. Indexes fill that bill. Third, the CREATE UNIQUE INDEX construct ends up preventing duplicates in a table, by placing a constraint on the index. At least that's how it worked in Rdb. Constraints on the data, whether declared or not, and whether enforced or not, really are part of the logical model. Fourth, the DEC Rdb/VMS command "show table" shows the indexes as part of its display. That's about it. This is like the death of a thousand cuts. I just don't want to fight this battle. Of course, if one is making a logical model with no idea of implementing it, all this is extraneous. I have never done that. I'm a database designer, not a theoretician. A logical model is a prelude to database construction for me. Otherwise, what's the point? >A little while ago, I remarked that I reluctantly included indexes in the > logical design, and Marshall asked why. [quoted text clipped - 4 lines] > tell you why I lean the other way. It's more a matter of several little > reasons than one big one. There is a very simple argument as to why indices do not belong to the logical mode: they are nothing more but a performance tool. > Before I start, after thinking it over, I've decided that it's more > precise [quoted text clipped - 15 lines] > objects". Tables and indexes are both included with the schema objects, > along with views, procedures, and other stuff. Well, it's just an arbitrary classification, an implementation pecularity if you will, which is not related to what indexes really are (see above). > Database objects are things > like tablespaces, that have no counterpart in the logical model. [quoted text clipped - 3 lines] > They should really need to see them, but they have a felt need. I'm > philosophical about it. That's odd. Why do programmers need to even know that a specific table has indexes (unless by a programmer you mean a database programmer of course) ? >If we're going to take away the pointers they love > to play with, we'd better throw them a bone. Indexes fill that bill. I do not understand the above. Are you talking about some psycological problems that can be settled if the hypothetical, non-database, programmer would know tha some table has indexes ? > Third, the CREATE UNIQUE INDEX construct ends up preventing duplicates in > a > table, by placing a constraint on the index. At least that's how it > worked > in Rdb. Constraints on the data, whether declared or not, and whether > enforced or not, really are part of the logical model. You are right of course that constraints are part of the logical model. However, the unique index is not. Such index is just an implementation vehicle for a unique constraint. Besides, in Oracle (with which you are apparently familiar) , a unique constraint can be enforced via a non-unique index. This piece of trivia should make it clear that an index, either unique or non-unique, is just a trick to improve performance. One can easily imagine a unique constraint enforcement without any index whatsoever although such enforcement would be impractical. > Fourth, the DEC Rdb/VMS command "show table" shows the indexes as part > of > its display. Surely, you realize that it's just an impementation pecularity, a convenient tool for the DBA. > That's about it. This is like the death of a thousand cuts. I just don't > want to fight this battle. [quoted text clipped - 4 lines] > designer, > not a theoretician. A logical model is a prelude to database construction Well, as a database designer, you convert your conceptual simplification of the 'real world' into a logical model and then you think how to implement this model using various tools at your disposal (indexes being one of them). Such impementation would be your physical model. > for me. Otherwise, what's the point? > "David Cressey" <david.cressey@earthlink.net> wrote in message > >If we're going to take away the pointers they love [quoted text clipped - 3 lines] > problems that can be settled if the hypothetical, non-database, programmer > would know tha some table has indexes ? It has to do with the real world. Nothing that needs to concern you, VC. > You are right of course that constraints are part of the logical model. > However, the unique index is not. Such index is just an implementation [quoted text clipped - 4 lines] > easily imagine a unique constraint enforcement without any index whatsoever > although such enforcement would be impractical. Not true. In DEC Rdb/VMS a unique constraint can be declared without creating an index, if you want to. There are actually cases, though rare, where that's the right thing to do. > > Fourth, the DEC Rdb/VMS command "show table" shows the indexes as part > > of > > its display. > > Surely, you realize that it's just an impementation pecularity, a > convenient tool for the DBA. Life is full of "implementation peculiarities". So far you've dismissed Oracle, Rdb, and Data Architect peculiarities as unimportant. What's left? > Well, as a database designer, you convert your conceptual simplification > of the 'real world' into a logical model and then you think how to implement > this model using various tools at your disposal (indexes being one of > them). Such impementation would be your physical model. Nope. There is more than one logical model that corresponds to the same conceptual model. You make choices based on the probable consequences downstream, after implementation. Some of this is hunch work, and not strictly mechanical. Again, it's from the real world. >> "David Cressey" <david.cressey@earthlink.net> wrote in message >> >If we're going to take away the pointers they love [quoted text clipped - 6 lines] > > It has to do with the real world. Nothing that needs to concern you, VC. Very cute. >> You are right of course that constraints are part of the logical model. >> However, the unique index is not. Such index is just an implementation [quoted text clipped - 9 lines] > Not true. In DEC Rdb/VMS a unique constraint can be declared without > creating an index, if you want to. For toy tables probably. In 'real world', no. > There are actually cases, though rare, where that's the right thing to do. For example ? >> > Fourth, the DEC Rdb/VMS command "show table" shows the indexes as > part [quoted text clipped - 7 lines] > Oracle, Rdb, and Data Architect > peculiarities as unimportant. What's left? What kind of argument in favour of indexes being part of logical model is that ? Are you familiar with the notion of relevancy ? >> Well, as a database designer, you convert your conceptual >> simplification [quoted text clipped - 7 lines] > downstream, after implementation. Some of this is hunch work, and not > strictly mechanical. What kind of argument in favour of indexes being part of logical model is that ? Are you familiar with the notion of relevancy ? > Again, it's from the real world. > > It has to do with the real world. Nothing that needs to concern you, VC. > > Very cute. Thank you. > > Not true. In DEC Rdb/VMS a unique constraint can be declared without > > creating an index, if you want to. > > For toy tables probably. In 'real world', no. In the real world, yes. > > There are actually cases, though rare, where that's the right thing to do. > > For example ? The exmples I would give aren't terribly germane to the main topic, nor would they prove any important points. So I'm ducking the question. > What kind of argument in favour of indexes being part of logical model is > that ? Are you familiar with the notion of relevancy ? Yes, the notion of relevancy IS important. But as long as you and I are as divided as we are about the nature of the real world, we are unlikely to come to a consensus about relevancy. [...] >> > Not true. In DEC Rdb/VMS a unique constraint can be declared without >> > creating an index, if you want to. It's unclear to what part of my first response to your original message "Not true" refers. Earlier, I wrote this: "One can easily imagine a unique constraint enforcement without any index whatsoever although such enforcement would be impractical". I did not claim that no database could implement a unique constraint without an index did I. It's interesting to note that by mentioning Rgb's ability to create a unique constraint without an index you actually reinforce my argument that the index is just a performance tool. >> For toy tables probably. In 'real world', no. > > In the real world, yes. It appears that in the "real world" you model the tables you want to have unique constraints on are either small, or you do not care much about concurrency when accessing such tables, or both. As is well known, accessing a table without an index will lead to a full table scan thereby impacting performance if the table is larger than a couple dozen rows. Besides, sequential retrieval for a read/write transaction requires locks on the entire table, which results in coarser locks and degraded concurrency. >> What kind of argument in favour of indexes being part of logical model is >> that ? Are you familiar with the notion of relevancy ? [quoted text clipped - 3 lines] > divided as we are about the nature of the real world, we are unlikely to > come to a consensus about relevancy. Does it mean that you actually do not have any technical arguments to substantiate your claim that indexes belong to the logical model, or in other words indexes are something else beyond being a performance tool ? > [...] >>> > Not true. In DEC Rdb/VMS a unique constraint can be declared without [quoted text clipped - 11 lines] > constraint without an index you actually reinforce my argument that the > index is just a performance tool. Indeed. There are two "possibly unexpected" ways to implement "UNIQUE": 1. Don't bother with any extra data structure; this would, of course, mean some form of sequential scan across the whole thing to verify uniqueness. 2. Use a hash table to allow access to values. This provides O(1) access time, but with the demerit that this structure is unordered, and therefore not usable for any other purposes... >>> For toy tables probably. In 'real world', no. >> [quoted text clipped - 6 lines] > impacting performance if the table is larger than a couple dozen > rows. Right. > Besides, sequential retrieval for a read/write transaction requires locks on > the entire table, which results in coarser locks and degraded concurrency. Not necessarily; alternative mechanisms exist, and are actively used. Pretty well any of the database systems still undergoing active development offer some variation of MultiVersion Concurrency Control (MVCC) where updates lead to creating new versions of tuples, which allows the reads, at least, to not require any locks...  Signature(reverse (concatenate 'string "moc.liamg" "@" "enworbbc")) http://cbbrowne.com/info/ If we were meant to fly, we wouldn't keep losing our luggage. [...] [VC] > > Besides, sequential retrieval for a read/write transaction requires locks on > > the entire table, which results in coarser locks and degraded concurrency. [quoted text clipped - 5 lines] > (MVCC) where updates lead to creating new versions of tuples, which > allows the reads, at least, to not require any locks... Sorry, regardings locks, I should have made it clear that I was answering in the context of Rdb/VMS that does not have MVCC. The little known Rdb/ELN, of which Interbase is a cousin, does implement MVCC and your argument holds there. > -- > (reverse (concatenate 'string "moc.liamg" "@" "enworbbc")) > http://cbbrowne.com/info/ > If we were meant to fly, we wouldn't keep losing our luggage. > Pretty well any of the database systems still undergoing active > development offer some variation of MultiVersion Concurrency Control > (MVCC) where updates lead to creating new versions of tuples, which > allows the reads, at least, to not require any locks... I'm not sure, but I think the Rdb/VMS "snapshot transaction" qualifies as "some variation on MVCC". In an Rdb database, read only transactions can be either locking or snapshot, depending on DBA decisions. In the case of snaphot transactions, commited updates do indeed cause the retention of before images of tuples (and of index nodes as well, by the way), but no row locking is needed to guarantee consistency for the snapshot transaction. A snapshot transaction could last for hours, while locking transactions proceed forward unhindered (expect for the extra overhead caused by retaining before images). Rdb/Eln used MVCC as its concurrency management tool, as VC said, and that's very different from Rdb/VMS. I briefly used a sub rosa version of "Rdb/Eln running on VMS" that was released internally in DEC a few months before Rdb/VMS. I don't know Interbase, but a quick look at its metadata organization strongly suggests that it was Rdb/Eln all over again. And the role that Starkey played also suggests the same thing. > Does it mean that you actually do not have any technical arguments to > substantiate your claim that indexes belong to the logical model, or in > other words indexes are something else beyond being a performance tool ? Why don't you just pretend that we had an argument, and that you won? That'll save us both a whole lot of time. >> Does it mean that you actually do not have any technical arguments to >> substantiate your claim that indexes belong to the logical model, or in >> other words indexes are something else beyond being a performance tool ? > >Why don't you just pretend that we had an argument, and that you won? >That'll save us both a whole lot of time. How about you acknowledge that you did not have much of an argument in the first place and that it was shot down (correctly)? There is no demerit to correcting oneself. There is to ranting on. Listening to someone trying to muddle together logical and physical models gets old fast. I prefer more precise language. If you want imprecise, talk to end users. They usually do not know computers very well, if at all. There is no need to wonder why it often takes a long time to get things straight with them. Sincerely, Gene Wirchenko > If you want imprecise, talk to end users. They usually do not > know computers very well, if at all. There is no need to wonder why > it often takes a long time to get things straight with them. That is exactly what I want to be able to do. I want to be able to talk to end users, in language they can understand. If that means being imprecise, so be it. I also want to be able to talk to programmers, and that's what got us started on this particular argument. I don't know how many programmers you've talked to. I've talked to hundreds. and the majority of them believe, correctly or incorrectly, that indexes are part of the logical design. Soo.... when I talk to them, I "muddle together" concepts that you consider to be disjoint or orthogonal, or whatever. Privately, I agree with you. But, for the sake of communicating with programmers, I choose not to fight this battle with them. Do I try to keep it straight in my own head? You bet! I understand perfectly well the differences between the consequences of bad table design and the consequences of bad index design. And, I did say, If you will look back to the topic starter, that I "very reluctantly" included indexes in the logical model, and that there was a great case to be made for excluding them from the logical model. That's the difference between me and most of the orthodox thinkers in this newsgroup. Most of you seem to think that a successful database application rests on logical thinking, and nothing more. Logical thinking is crucial, but it's just the beginning. The politics of information, industrial psychology, resistance to change, and a host of other human factors are critical success factors as well. And to me, the reason I include indexes in logical models is precisely due to these human factors, and not because logic demands it. Regards, Dave > And to me, the reason I include indexes in logical models is precisely due > to these human factors, and not because logic demands it. I too live in the horrible, messy, opinionated, perverse, deluded, intractably mis-informed Real World, so I have considerable sympathy for what you say. But given that this is a theory group, maybe we should invent a new model which includes indexes, say, the "political model". ;-) We shall take it for granted that the political model is beyond the reach of reason and logic. The mob shall be its animus, moderated by bovine indifference and the need for a herd. That is where things not demanded by logic belong. Roy > David Cressey wrote: > [quoted text clipped - 5 lines] > what you say. But given that this is a theory group, maybe we should invent > a new model which includes indexes, say, the "political model". ;-) Why not the "feasibility model"? Surely some - but not all - indexes will have to be studied very early on in large projects, just like some - but definitely not all - logic has to be crystallized from contradictory early wishes, demands and expectations. I see no reason to push indexes into the realm of logic of user data just because we need to study some of them early. We can explore them without putting them on the wrong shelve, can't we? > We shall take it for granted that the political model is beyond the reach of > reason and logic. The mob shall be its animus, moderated by bovine > indifference and the need for a herd. That is where things not demanded by > logic belong. > > And to me, the reason I include indexes in logical models is precisely > due [quoted text clipped - 9 lines] > indifference and the need for a herd. That is where things not demanded by > logic belong. Interesting point of view. I hang out in this group due to the lack of a database design newsgroup. And so perhaps my comments concerning how to make a database project successful are out of place here. The scope and use of the political model will depend on what parts of the project are subject to politics. In my experience, the database model shared between "the database group" and "the programmers" has always had a political function. These are two groups that each have enough power to wreck the project, and perhaps enough power to collaborate on a success. Their interaction is decidedly political. Due to what might be a historical accident, the model of the database made visible to the programmers has been called the "logical model", in my experience. And, prior to my arrival on the scene, this "logical model" (actually political model) had generally, though not always, lumped the indexes in with the tables. I found it convenient (prehaps "politically correct") to go along. Besides, knowing the indexes helps the programmers to better queries. So I live with it. > Due to what might be a historical accident, the model of the database made > visible to the programmers has been called the "logical model", in my > experience. Actually that is something I have been fretting about recently. In the real (i.e. SQL) world there are actually two physical models: the one the programmers are required to see (for whatever reason), and the ones they are required (or asked) to pretend they don't see. The one they are required to see might have extra tables that were introduced when vertical fragmentation is the only solution to a performance problem. Or it might have fewer tables than the logical model, because (rightly or wrongly) the design has been denormalized (again for performance reasons). There are innumerable other reasons why extra tables are introduced, and others merged. But the tables in this model have to be known and explicitly manipulated by the SQL the programmers write, or at least be capable of it. The other physical model (the one the programmers are supposed to ignore) is the one in which the secondary indices are exposed, and maybe the base tables that are really only meant to treated as the basis of views. The fragments of horizontally fragmented tables are perhaps also visible here. This is the DBA/system admin's view of the database. The tables in this model generally are all too visible, but the programmers would be imprudent (frankly, wrong) to explicitly manipulate them. The DBA must always be at liberty to change anything in this model that is not also in the "other" physical model, without breaking the applications. There are clearly two different physical models. > And, prior to my arrival on the scene, this "logical model" > (actually political model) had generally, though not always, lumped the > indexes in with the tables. I found it convenient (prehaps "politically > correct") to go along. OK so far. Or at least I choose not to argue about it. > Besides, knowing the indexes helps the programmers > to better queries. [snip] This does bother me. What kind of rubbish DBMS requires the programmers to be aware of an index in order to write "better queries? Assuming we're talking about SQL here, the only way knowledge of an index can help them write better code is by involving the index explicitly in a FROM clause. So what happens when the DBA decides the index is not efficient and drops it? What happens when the optimal execution strategy would be to ignore the index, but there it is, hard-coded into the SQL? But perhaps I am misunderstanding you. Perhaps when you say "knowing the indexes", what you mean is "knowing the alternate physical keys"? The alternate keys definitely belong in the first of my physical models above, not with the indexes in the second. By referring to one of these in the WHERE clause the programmer certainly could write better code. And if the alternate keys happen to coincide with candidate keys (as the easily could) then they already appear in the logical model. (Of course an alternate physical key need not be a candidate key--it might be deliberately ambiguous, to encourage physical clustering of related data.) I really am not happy about programmers calling my first physical model a "logical model", but what they call it doesn't change what it is. And if they call it the wrong thing, perhaps that's because in SQL there are two physical models but only one name. They just *can't* make clear which one they mean. Roy > > Due to what might be a historical accident, the model of the database > made [quoted text clipped - 5 lines] > programmers are required to see (for whatever reason), and the ones they are > required (or asked) to pretend they don't see. Good point. For this reason, I've recently turned away from calling the SQL model "logical" at all, and instead saying that the tables are the reflection of the logical model in the implementation. That leaves open the question of what the indexes really are. If I have to say something that makes sense to me, I'm going to say that the indexes reflect the transaction model in the implementation. However, so do things like table partitions. At this point, we really have to get down to "what's wrong with SQL". It seems as though the relational data model is capable of greater logical data independence that is possible for programmers who see the RDM through the lens of SQL. But I'll defer to others on that question. > The one they are required to see might have extra tables that were > introduced when vertical fragmentation is the only solution to a performance [quoted text clipped - 4 lines] > known and explicitly manipulated by the SQL the programmers write, or at > least be capable of it. > The other physical model (the one the programmers are supposed to ignore) is > the one in which the secondary indices are exposed, and maybe the base I'm assuming that by "secondary indexes" you mean the ones that don't emerge directly from the definition of primary keys. And this reminds me of a subtle difference between Rdb/VMS and Oracle RDBMS that has tripped up more than one Oracle RDBMS expert who has been asked to work on Rdb/VMS. When you declare a primary key in Oracle, Oracle makes an index for you. In Rdb/VMS it does not (unless that's been added in recent versions). The consequence is that you end up with some tables with no indexes that the designer never would have left that way intentionally. But all this is a product specific digression. > OK so far. Or at least I choose not to argue about it. That's EXACTLY my position. I choose not to argue about it. I choose not to argue about it with the logical thinkers in this forum. Have it your way. I also choose not to argue about it at the places where I was called in to lend my expertise. Have it your way. And if the programmers at client sites, and the logical thinkers in here desperately need an argument clinic, why I'll simply introduce them o each other! > > Besides, knowing the indexes helps the programmers > > to better queries. [snip] [quoted text clipped - 3 lines] > talking about SQL here, the only way knowledge of an index can help them > write better code is by involving the index explicitly in a FROM clause. It's even worse than you imagine. I can't tell you the number of times that a programmer has approached me with a query that has a "performance problem", they wanted help with. It turns out that the query has a logical error in it, and the logical error causes it to deliver wrong results 10 to 50 times more slowly than it should. When you fix the logical error, the "performance problem" mystically disappears. Why programmers want to speed up a query that's giving wrong results is a continuing mystery to me, and I don't epxect to ever understand it. But, by golly, show them allthe indexes, and teach them how to tell which indexes the optimizer invokes, and they find a lot more of their own bugs than they did before, in the course of making their programs perform well. Explaining this behavior to logical htinkers is like Mr. Spock explaining earth to his fellow Vulcans. > what happens when the DBA decides the index is not efficient and drops it? > What happens when the optimal execution strategy would be to ignore the > index, but there it is, hard-coded into the SQL? > But perhaps I am misunderstanding you. Perhaps when you say "knowing the > indexes", what you mean is "knowing the alternate physical keys"? See above. > The > alternate keys definitely belong in the first of my physical models above, [quoted text clipped - 4 lines] > physical key need not be a candidate key--it might be deliberately > ambiguous, to encourage physical clustering of related data.) This all depends on how smart the optimizer is. Back in 1994, the Rdb optimizer was a LOT smarter than the Oracle optimizer. I got spoiled by the Rdb optimizer. That's a whole other discussion. > I really am not happy about programmers calling my first physical model a > "logical model", but what they call it doesn't change what it is. And if > they call it the wrong thing, perhaps that's because in SQL there are two > physical models but only one name. They just *can't* make clear which one > they mean. Maybe the best distinction (in the terminology) is the one Data Architect makes: between "Schema Objects" and "Database Objects". But I'm not sure. This opens a whole other subject. If a database gets "denormalized" in the course of implementation, perhaps its good to keep a copy of original normalized model around, and in synch with whatever alterations get made to the implementation. That way, someone who wants a REAL logical view of the relations can get such a view without the obstructions imposed by SQL and by real world considerations. Is it worth the cost? I don't know. > Maybe the best distinction (in the terminology) is the one Data Architect > makes: between "Schema Objects" and "Database Objects". But I'm not sure. Say that you have a schema in the RM, and let this schema hold true in one particular database. As the database (data) changes with time, this schema holds true in all these databases. Besides having some simple language L, the schema can have some constrains. Let us call the database "a good one" if the constraints are satisfied in the database. Briefly a database is a model for a schema. Say that now somebody else designs an OO schema and let this schema hold true in the OO databases with same data. If there is a correct mapping (or maybe morphism) between mentioned RM schema and the OO schema, then I believe that we have something which we can call Janus with two faces, but one Conceptual Model. > This opens a whole other subject. If a database gets "denormalized" in the > course of implementation, perhaps its good to keep a copy of original > normalized model around, and in synch with whatever alterations get made to > the implementation. That way, someone who wants a REAL logical view of the > relations can get such a view without the obstructions imposed by SQL and by > real world considerations. Is it worth the cost? I don't know. Vladimir Odrljin >> If you want imprecise, talk to end users. They usually do not >> know computers very well, if at all. There is no need to wonder why [quoted text clipped - 3 lines] >end users, in language they can understand. If that means being imprecise, >so be it. But if the end result needs to be precisely defined? At some point, the imprecision must be removed. >I also want to be able to talk to programmers, and that's what got us >started on this particular argument. I don't know how many programmers [quoted text clipped - 4 lines] >you. But, for the sake of communicating with programmers, I choose not to >fight this battle with them. So if you were to talk to me (programmer/analyst), you would a) sound as if you do not know what a logical model is, and b) possibly expect something from me that does not belong. (I would turn in a logical model WITHOUT indexes.) It hardly need be a battle. "That is part of the implementation. We are still on the logical model." >Do I try to keep it straight in my own head? You bet! I understand >perfectly well the differences between the consequences of bad table design >and the consequences of bad index design. And, I did say, If you will look >back to the topic starter, that I "very reluctantly" included indexes in >the logical model, and that there was a great case to be made for excluding >them from the logical model. Yes, but you still did it. If you are going to be informed by other people's ignorance, you are going to muddle. There goes precision. In medicine, "femur" is well-defined. It would not be acceptable to use the term as a synonym for "leg bone". >That's the difference between me and most of the orthodox thinkers in this >newsgroup. Most of you seem to think that a successful database application >rests on logical thinking, and nothing more. Logical thinking is crucial, No. It is necessary but not sufficient. It is necessary. >but it's just the beginning. The politics of information, industrial >psychology, resistance to change, and a host of other human factors are >critical success factors as well. Of course. All the politics will make no difference if the logic is not there. How many projects fail? >And to me, the reason I include indexes in logical models is precisely due >to these human factors, and not because logic demands it. If anything, logic demands that it not be there. Sincerely, Gene Wirchenko > Before I start, after thinking it over, I've decided that it's more precise > to say that indexes and tables (in an SQL implementation) are not the > logical model as such. They are the reflection of the logical model in the > implementation. That sentence works just fine for me. I'll also agree with your point that, in fact, we working programmers actually do have to make these things we design work, and that definitely includes performance. A purely logical model is by itself not useful in building software (although it is useful in analyzing software.) It has to be coupled with an implementation to work. Marshall |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.