To whoever hacked into my Database

[rurpy at yahoo.com]

On 11/11/2013 04:49 PM, Joel Goldstick wrote:
> On Mon, Nov 11, 2013 at 5:47 PM,  <rurpy at yahoo.com> wrote:
>> On 11/08/2013 11:08 AM, Chris Angelico wrote:
>>> On Sat, Nov 9, 2013 at 4:11 AM,  <rurpy at 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.)