FMPRO-L Archives

December 2011, Week 4

FMPRO-L@LISTSERV.DARTMOUTH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Geoff Graham <[log in to unmask]>
Reply To:
FileMaker Pro Discussions <[log in to unmask]>
Date:
Thu, 22 Dec 2011 16:11:14 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (100 lines)
Well said. I think in this case it might be a difference of terms: The document number is not really an identifier of a document; simply its sequence within its container. If container number 4 was pulled off at the last minute, then there are now 19 containers going to a port instead of 20. They can still be listed (and apparently must be) as containers 1 thru 19 of this particular shipment. Of course all of your records that represent real-life entities should have a unique id; but that doesn't really have anything to do with the customer's request. In real life, here we have items within a container that need to be labeled in natural order, 1 thru whatever; and the customer is asking for the database to reflect that. 

The customer and I are already on the same page here; have your database represent real life as closely as possible. The closer you get to that goal, the less problems you will have down the line. Fancy abstractions help no one. In this case, I'm wondering what exactly should be the unique identifier of a container/shipment/whatever it is. Obviously not the numeric label it's going to get at ship time; but something. Once I answer that single (but possibly hard) question; the rest of development is a simple matter of dropping fields on screen and scripting out the operations. 

Like laying tracing paper over real life, all I have to do is follow the lines.

Geoff

> -----Original Message-----
> From: FileMaker Pro Discussions [mailto:FMPRO-
> [log in to unmask]] On Behalf Of Jonathan Fletcher
> Sent: Wednesday, December 21, 2011 8:11 PM
> To: [log in to unmask]
> Subject: Re: Client Communications [Was: Serial number]
> 
> It's a common technique in discourse these days to impugn the intelligence
> of those we disagree with it. All sides do it frequently in the polarized world
> of political conversation in the media, but it pervades all levels of our
> existence. We cannot imagine why someone would even deign to think a
> particular way so we call them "Philistine" and even "Nazi."
> 
> The problem lies not in their intelligence or malevolence, however, but in our
> inability to understand their motivation. If we truly understood WHY they
> wanted something a particular way we would be better prepared to show
> them a better way, as opposed to stamping our pretty little prima donna
> pointe-clad foot and demanding that they see our way as the One True way.
> 
> Then there's always the risk, to our extreme discomfort, that the other
> person might have a perspective that, upon further examination, we might
> find enlightening.
> 
> After reflecting on this little back and forth, I am getting kind of curious as to
> why the client thinks that recovering document numbers is _essential_ to
> their business model. The answer to that question might provide clues as to
> what makes them tick.
> 
> That just might be a GOOD thing to know.  ::-)
> 
> j.
> 
> 
> 
> 
> On Dec 21, 2011, at 7:04 PM, Richard S. Russell wrote:
> 
> >
> > On 2011 Dec 21, at 17:42, Corn Walker wrote:
> >
> >> On Dec 21, 2011, at 6:18 PM, Richard S. Russell wrote:
> >>
> >>> As I am retired and do my database work entirely pro bono for deserving
> non-profit organizations, I am not unduly constrained by the profit motive, so
> I can call 'em as I sees 'em.
> >>
> >> Would you not agree that it is preferable that one be charitable rather
> than derogatory? I see this as an opportunity both to better learn the
> motivations behind the request as well as educate the client about best
> practices in design and ways that a database system might improve upon
> their process. Both parties come out ahead and feeling positively about the
> experience rather than adversarial.
> >
> > You are right as usual, Corn.
> >
> > I just get frustrated at people who will hire somebody who's competent at
> databases specifically to WORK on databases and then ignore or flout best
> database practices as if they know better. It's as if I hired an auto mechanic to
> fix my car (a subject about which I know nothing) and insisted that he or she
> had to insert a particular brand of carburetor because my dad always used
> them, utterly oblivious to the fact that modern cars don't even HAVE
> carburetors any more.
> >
> > Why hire an expert if you don't want to listen to expert advice? Heck, hire
> your shiftless cousin Vinnie. He'll do whatever you tell him, with no hifalutin
> backtalk, and he probably needs the money more.
> >
> > = = = = = =
> > Richard S. Russell
> > 2642 Kendall Av. #2
> > Madison WI 53705-3736
> > 608+233-5640
> > [log in to unmask]
> > http://richardsrussell.livejournal.com/
> >
> > Sun god! Sun god! Ra, Ra, Ra!
> >
> 
> 
> --
> Jonathan Fletcher
> FileMaker 9/10/11 Certified Developer
> 
> Fletcher Data Consulting
> [log in to unmask]
> http://www.fletcherdata.com
> 502-509-7137
> 
> Kentuckiana's FileMaker Users Group
> Next HOLIDAY TREAT SHARING: Tuesday, December 20, 12:00 pm to 3:00-ish
> Blog: http://www.kyfmp.com

ATOM RSS1 RSS2