Re: Navigation question
Date: Sun, 18 Feb 2007 22:01:30 +0100
Message-ID: <45d8bebd$0$334$e4fe514c_at_news.xs4all.nl>
dawn wrote:
> mAsterdam wrote:
>> dawn wrote: >>> mAsterdam wrote: >>>> dawn wrote:
>>>>> I'm still trying to get a straight answer to the question about >>>>> navigation.
>>>> Which straight question?
>>> For one, from the original post "Do large, production-quality, highly >>> usable and useful, data-based, >>> read-and-write software applications actually exist where there is no >>> code in the software that navigates around the database?"
>> I read that one. It did not qualify as a straight question to me.
>> Is "take a pointer value, find out what is at the location it is >> pointing to, evaluate that" navigation?
> If it does not, then I would like to know what navigation means to
> others. I "navigate" through a database by moving from foreign key
> value to a row in a table that it leads to. If navigation means
> something else, please advise.
A simple 'yes' would have done some unloading of the question.
You are the one asking, you decide what you mean with the terms in
your question. However, now you go back drawing in foreign keys
as a navigational thing again.
Has anybody ever agreed with you that they are?
Why do you think there is here, there, movement
involved in foreign keys?
As soon as you think of foreign keys as a navigational thing, you are thinking outside the scope of the 'foreign key' concept. There is no movement there. I can see person figuring out a query by following the lines in a picture of a database structure with his index finger. Yes he is navigating. However, if he is not able to realize that this is just a third wheel on the bicycle help get him started, he is not the person I'd trust writing queries.
The things I understand from your (anything but straight) question have been answered many times by now. I suggest you now start summarizing what you picked up from the answers - from just the answers. Giving such positive feedback is at times necessary.
Aside: I am still waiting to see that you
have recognized the difference between documents
and data, for instance.
You said you got it - but I haven't
seen you /use/ that understanding yet.
>>> Some have said "yes" but then removed any OLTP from the system or at >>> the very least (re)define "navigate" so that data from a prior result >>> set may be used to seed another resultset if there is a user event >>> between the two database reads (such as SQL statements). >> Please read the post before you start answering. >> You are repeating stuff I responded to.
>
> In this case I read sequentially and responded as I read. Is that
> rude? If so, my apologies.
You don't have to make a how-to rule or a principle from every reply. TIMTOWDI. This comment was stale by the time you posted. You could have deleted it.
[snip]
> I'm not so interested in physical navigation,
> but the logical (app code) navigation.
This terminology does not sound right.
Go here, go there is about location - something physical, no?
>>> Is the following pseudocode that includes navigation a poor way to >>> code this and, if so, why?
>>> select companyid c, companyName, emailAddress >>> from Company c, EmailAddr e >>> where c.companyid=e.companyid and tin='xyz';
>>> thisCompanyid=companyid;
>>> select classifier from CompanyClassifier where >>> companyid=thisCompanyid;
>>> select orderid, orderPrice from Orders where companyid=thisCompanyid;
>> "poor" could be overly harsh - but, compared to a single query, >> it /does/ introduce some arbitrary ordering, inspired by how the coder >> thinks the data is to be located - which may or may not be the case or >> may change in the future.
> What kind of changes would be problematic?
Not just changes; all current and future differences from 'how the coder thinks the data is to be located'.
I can't pinpoint what it is you do not see here. To me this really seems more than obvious from what I wrote.
It looks like you do not read the answers, but skip them and restate your opinions (sometimes disguised as questions) with a few borrowed words.
>> The single query would have no such dependency.
>
> How would you code the application, perhaps including a total line for
> the total price after the list of orders presented to the user, if you
> put this in a single SQL statement? It is certainly possible, but
> ugh, that cross-product is not pretty.
Which cross-product?
>>>>> Is there something wrong with taking information from one >>>>> query, for example and using it to retrieve data in another query. >>>> If this is the straight question, then the answer is yes. >>>> It depends on the situation how relevant the wrong is. >>> OK, why? >> 1. The 1st query data may be stale at the time of the second query.
>
> Yes, agreed.
>
>> 2. The 2 queries may have optimizer synergy.
>
> So that instead we might have wanted to do what?
? Not prohibiting the optimizer from doing its job.
>> If performance is not an issue,
>
> I definitely care about performance, recognizing tradeoffs.
>
>> 2. won't bite you. >> If actuality isn't an issue, 1. won't bite you.
>
> If 1 might be problematic, then freezing the data first might be
> required.
That only accomplishes that all data is guaranteed to be equally stale. Congratulations, you have just discovered the data warehousing approach.
>>>>> The answer to this is "no" for those cases >>>>> where there is user input between the two statements, >>>>> >>>> How so? >>> If the user lets us know on one screen that they want the company with >>> tin='xyz' whereupon we show them a screen with the above information >>> (tin was not designed for that screen), they make changes, and we read >>> the data (or just the changes) from the screen, are we then permitted >>> to "navigate" by using the companyid we read in to seed SQL statements >>> for updating data, or must we go back to the original data the user >>> gave us? That seems like it would just be a game to do that, but >>> perhaps there is a reason to do so?
>>>> The answer to the first query may have changed during user input.
>>> If the user has access to change it.
>> Or another user has access to change it.
>
> Ah, I understand the point now. How to handle would depend on the
> specific requirements. In this case, we accessed data using a
> "secondary key" then used the "primary key" to get the relevant data
> from another table.
You are giving me a hard time.
Yes, this is the kind of positive feedback I am looking for so
I can check if what (several others and) I wrote came across
- but, unfortunately:
No, this is not the point. Primary/secondary keys have nothing to do
with this.
>>> We could narrow the question down to situations where that >>> original information remains unchanged, >>> if that helps. >> Helps what? Getting to a situation where it is ok to >> hand-navigate at a logical level without drawbacks?
>
> No, helps in answering the question of whether there are requirements
> that would make it OK to navigate.
I expect them to be in your summary :-)
>> /Wanting/ navigation without drawbacks, obviously >> as soon as a drawback is mentioned, looking for a rephrase >> that excludes this particular drawback is the way to go.
>
> Yes, because I'm trying to understand if navigating through data is
> always a bad thing, and, if so, why. So, if you come up with a
> situation where it is bad, then remove that one. Is there anything
> left?
>
>> This shows that the up front question wasn't straight but loaded.
>
> Nope. I honestly haven't seen a significant application that did not
> have data navigation in the application logic. I'll grant that I
> haven't been heads down in code for weeks on end since 19xx. So, when
> I was thinking about this, I took a look at some current production
> code and, yup, there was navigation in it. So, my question was
> straight forward. The answer was that there are such apps. So, then
> I'm curious whether navigating through data is always bad and, if so,
> why.
You have the answers. Why ignore them?
Here is a tip to get focus: copy and paste the whole thread into one
file. Edit it:
1. delete everything you wrote. 2. delete all insults. 3. summarize. >>>>> but I'm still uncertain if there is>>>>> something wrong with doing this when there is no such event in the >>>>> midst.
>>>> What would be the reason for doing this if there is no such >>>> event in the midst?
>>> My question is actually what the reason would be for not doing it. I >>> don't advocate that one must code it as above, but my understanding is >>> that any such "navigation" is seen as somehow flawed and I have not >>> yet figured out just what it wrong with it.
>> You did not answer my question.
>> One answer could be: it is easier to compose the queries that way:
> I guess one possible reason is that the designer thinks that way and
> is unaware of a reason not to navigate in this instance.
Who put him on this job?
>> Thinking like I go here get this stuff, then I go there and get that. >> I'd say go ahead on non time-sensitive data on noncritical systems. >> As soon as these conditions change, consider rephrasing >> the query as one.
>
> I would like to pursue this further.
Your summary would be a good starting point.
> I have used what I considered to
> be oddball star joins in a non-standard product that would somewhat
> help, but have not used Oracle or standard SQL-DBMS star joins. Is
> there some type of join that would help us get this data back into a
> nice resultset? Otherwise if there were 3 e-mail addresses, 4
> classifiers, and 10 orders, the resultset I would get back would have
> 120 rows, right? Then what is the best way to go from there to my
> single page of data?
Received on Sun Feb 18 2007 - 22:01:30 CET