On 11/11/2013 04:49 PM, Joel Goldstick wrote: > On Mon, Nov 11, 2013 at 5:47 PM, <ru...@yahoo.com> wrote: >> On 11/08/2013 11:08 AM, Chris Angelico wrote: >>> On Sat, Nov 9, 2013 at 4:11 AM, <ru...@yahoo.com> wrote: >>>> On 11/08/2013 03:05 AM, Νίκος Αλεξόπουλος wrote: >>>>> I never ignore advices. >>>>> I read all answers as carefully as i can. >>>>> But nevertheless sometimes i feel things should have been better >>>>> implemented using my way. >>>>> >>>>> Not of course that i know better, but thats better suited for me in the >>>>> level iam. >>>> >>>> Most of the "advice" I've seen posted here has, as far >>>> as I can tell, not intended to be useful but to serve >>>> as a way to telling you are incompetent are in other ways >>>> insulting or useless. I think you are quite right to >>>> ignore it (or tell the poster to get lost.) >>> >>> Actually no; most of the advice has been genuine. >> >> Actually yes; most of the advice has not been genuine. >> >> Of course neither you nor I know for sure since we can't >> read minds. But when "advice" consists of things like >> "Maybe try some of the advice you have been given instead? " >> "use php" > > It seems like you take the view that people have decided to bully or > tease or laugh at this one person here. Sometimes other's ask > question and they quickly get gently (maybe not gently) teased, but > since I have been listening here it is one person overwhelmingly who > gets this response. It doesn't mean its really the highest order > behavior, but its not done in a vacuum either.
I do not (as another poster put it) think that Nikos is an "innocent" being picked on. I do think that this group would be a better place were those who enjoy baiting, flaming and otherwise venting their frustration with Nikos to vent in some other private way, but it seems I was unable to convince anyone else of that (or at least any of those who do it most). I am not unequivocally defending Nikos but in this particular case, where he is being bashed for not accepting a "solution" that doesn't meet his needs (as he sees them), I think he is right. >> "Try starting with something simple. The following is a >> step by step guide... Now, and this is really really >> going to tax you..." > > So, you don't like teasing. Why not go back and see where this > teasing started. I would guess that its not from the beginning. Its > only after a history that makes it appropriate (maybe not appropriate, > but understandable). Ridicule is a more accurate description than teasing. And you're right, I don't like it. Yes, it's understandable (in the same way it is understandable that the victim of a crime might want to murder the perpetrator) but that doesn't make it acceptable. >> A treatise on 1nf in six short sentences followed by >> ruminations on competence including "...never shows >> a glimmer of interest in learning." > > This one I think is mine. I don't pretend to be able to write a > treatise in however many sentences, let alone 6. This 'guidance' was > to provide a link to a more substantial authority than me about why > its a bad idea to use a database without normalizing data. If you > want to get stuff out of a database with sql you have to normalize it, > or know well why you would not. The thread about normalizing > degenerated (sorry if the term is loaded) into people talking about > various language data types that can be stored in a sql database. > Blob, is the one I remember. So, if you refuse the idea that its > better to build a second table with a one to many relationship to the > first table rows, then you need to know how much python code will be > required to reverse that 'shoving stuff' in a single column. Its a > choice. Right, that's my point. It is a choice with tradeoffs; either option will have some advantages and some disadvantages. He was trying to figure out the Python code needed. And your suggestion is not necessarily best either: why a 1:M relationship? why not a M:M relationship? There may be duplicate file downloads resulting in your suggestion being non-normalized. So I think there is some justification in his looking for a simpler Python solution even if it is not the way the majority here would do it. >[...] >> No you're not. Without determining how the data is to be >> used you can't say it's not normalized. Otherwise one >> could claim every of the millions of databases containing >> addresses is not even 1nf because their designers crammed >> two pieces of information (street number and street name) >> into a single datum. > > Talking about whether an address is atomic is a can of worms. Anyone > who has worked with addresses finds this out. But in the generic > sense an address is a single description of a location. Saying that > it should be two fields, one with number, and one with name doesn't > sound right to me because each field is too small to have any meaning. Of course it has meaning. The number identifies a location on a street. My point was that what is "atomic" depends on *you* and how *you* analyze your data (which depends on how you intend to use it.) If you don't care about being able to group by street name, then the composite field (street number, street name) is, for your purposes, atomic. Saying to someone that a separate table is usually best, pointing out potential problems with a non-atomic datum is good, saying dogmatically IT IS WRONG is itself wrong. I haven't read much of the other Nikos thread (no time this month) and it may well be that faced with the same issue myself, I would use a separate table. But I think he is being perfectly reasonable in rejecting a separate table if he feels it does not meet *his* needs (even if he is wrong in your opinion.) Given the invective and hostility directed at him, I have no problem supporting him *on this issue*. As an aside, one frequently sees similar dogmatic overstatements here: "never use eval()", "ALWAYS use bind parameters in sql statements", "NOBODY uses cgi", diatribes against regular expressions or xml, and so on. All of these may be generally true but there are plenty of exceptions, and if a poster, having been informed of why they should be avoided, decides (rightly or wrongly) that those reasons don't apply to him for some reason, I think his decision should be respected even if you don't agree with it. (Doesn't mean you have to provide an answer, just don't become offensive because he wouldn't do what you told him to.) -- https://mail.python.org/mailman/listinfo/python-list
