sql module and radgroup...

[pele]

but we are! I was just brushing up on my flame-war skillz! :-)
Just idle chit chat really I'm already working on some patches for you  
guys.
No offense meant

Sent from moba.hotspot

On 9 Jul 2010, at 19:47, Gabriel Blanchard <gabe at teksavvy.ca> wrote:

> can't we just all be friends!!! :-))
>
> On 2010-07-09, at 1:43 PM, predrag balorda wrote:
>
>> On 9 July 2010 17:54, Alan DeKok <aland at deployingradius.com> wrote:
>>> predrag balorda wrote:
>>>> Well, read it, over and over again, until you do.
>>>
>>> A useful suggestion, I'm sure.
>>>
>> It is, indeed.
>>
>>>>>> Then you can draw all sorts of relations back to this table from
>>>>>> radgroupcheck, radgroupreply, usergroup etc.
>>>>> Sure.  That's useful, but not required.
>>>>
>>>> Useful but not required? Interesting postulate. Then all my rdbms
>>>> professors were and everything I know about rdbms is wrong, I
>>>> guess....
>>>
>>> Practice != theory
>>
>> Practice == theory, it's just that your Practice != longEnough. Tsk.
>>
>>> I've seen situations where referential integrity can be enforced by
>>> the provisioning tools that write to SQL.  This gets the benefit  
>>> of the
>>> integrity without the complicating the SQL tables.
>>>
>>> And it can give a 2x performance gain.  Real world, not theory.
>>
>> I'm sure that's true. Let's all go find tools to do the work for us
>> since we are brain-dead and can't be arsed to follow some simple  
>> rules
>> set-out 50 years beforehand. Because we have "Practice". 1337.
>>
>>>> I haven't _seen_ those, per se, but I have _worked_ on some that  
>>>> were
>>>> 7, 8 and 9 figure commercial solutions with less and more  
>>>> referential
>>>> integrity than the default FreeRADIUS schema. What are you trying  
>>>> to
>>>> do? Impress me? Or say that if some XYZ company doesn't do it then
>>>> it's not worth doing?
>>>
>>> Read my response until you understand it.
>>
>> I did, perfectly. My eyes glazed over.
>>
>>>> So if Microsoft doesn't check for buffer underruns and overflows in
>>>> their code it isn't worth implementing in your FreeRADIUS code?  
>>>> Again,
>>>> interesting postulate. I'll have to go read up a bit on that.
>>>
>>> Ah, yes.  If you can't have a rational discussion, invent an
>>> irrational one, and accuse the other guy of being irrational.
>>
>> Proves my point again. Let's all go out and find tools because 7
>> figure companies don't do it why should we.
>>
>>>>>> svn) repository sometime next week
>>>>>>
>>>>>> 'git'.
>>>> 'pufter'
>>>
>>> That comment is either ignorance ('git' is a revision control  
>>> system),
>>> or is a deliberate attempt to be an idiot.
>>>
>>>> Yes, and one more thing to stop the server from keeling over.
>>>
>>> Nonsense.  The server has *never* died or failed because of a lack  
>>> of
>>> referential integrity in SQL.  The server simply returns the data  
>>> you
>>> *told* it to send, instead of the data you *wanted* it to send.
>>>
>>> This is *not* a problem with the server.  It's a problem with the
>>> administrator.
>>
>> Ah right, another BOFH to keep us amused. Nope, sorry, Simon did it  
>> 15
>> years ago. Been there, done that.
>>
>>>> And one
>>>> more thing to stop the server from replying with crap  
>>>> information. And
>>>> one more thing to stop people from making mistakes. And one more  
>>>> thing
>>>> to stop people from loosing account information. And one more  
>>>> thing to
>>>> make code easier to read and understand. And one more thing to make
>>>> bug-finding easier. And one more thing to increase performance. And
>>>> one more thing to reduce database size. And and and....
>>>
>>> And one more thing for people to get wrong.  And one more step for
>>> people to take before they can add data to the tables.  And one more
>>> performance hit.  And...
>> Nope, you lost me there. How does, exactle, referential integrity  
>> stop
>> someone from adding data to a table? Huh? How does referential
>> integrity impart a performance hit in a _negative_ sense? Erm, yes,
>> keep taking those pills.
>>
>>> There's a practical thing called "real-world trade-off".  Or "cost  
>>> and
>>> benefits".  It's not as black & white as you seem to believe.
>>
>> I know, I practically invented the term. 0 is black, 1 is white.  
>> Sorry
>> but that's the world of computer science to you and me. There is no
>> gray area, everything has been invented, you just have to apply it.
>>
>>>>>> I'm probably talking crap here as I'll be switching to LDAP soon
>>>>>> enough for all this to go away, but still. It'd be nice.
>>>>> As always, patches are welcome.
>>>>
>>>> Again, I just did!
>>>
>>> No.
>>>
>>> You posted a simple schema that is *unrelated* to the existing ones.
>>> You then waved your hands saying "yeah, someone else can update the
>>> schemas to use this one."
>>>
>>> And then you get snarky when I ask you to post a more useful  
>>> patch...
>>>
>>>> Ok, and now seriously.
>>>
>>> Ah... thanks for wasting my time with wise-ass comments.
>> You already wasted enough of my time with your futile and uneducated
>> attempts at belittling the work of others at defining what now
>> supports probably more than 70% of your daily activities by saying
>> they are all ignorant idiots who came up with a perfect solution to a
>> simple problem called "integrity", so I figured I might as well waste
>> some of yours. After all, my time is not free. So there.
>>
>>>> I'll look into your schema and see what can be
>>>> done. I've already begun modifying it as I go along. Would you  
>>>> prefer
>>>> a set of simple statements to create tables or would you rather  
>>>> alter
>>>> existing ones? I think altering existing ones would make all hell
>>>> break loose, but I can try?!
>>>
>>> You're the SQL expert.  You figure it out.
>>> And my opinions in the matter are from real-world experience.  I am
>>> very, very wary of "database experts" doing "database  
>>> optimizations".
>>> They nearly always fail in the real world.  The "database experts"  
>>> then
>>> say "it's not our fault", and the poor RADIUS admins are left to  
>>> clean
>>> up the pieces.
>>>
>>> I *don't* have a lot of respect for much of the fascination with SQL
>>> referential integrity.  It's useful, but just one tool that can be  
>>> used.
>>>
>>> Alan DeKok.
>>> -
>>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
>>>
>>
>> I'd be a rather sad person if I called my self _only_ an SQL  
>> expert. I
>> tend to think of myself as much more.
>> And if, by "database optimizations" you mean simple and basic  
>> database
>> normalization then I shall give up and go have me something to eat  
>> and
>> drink down the local. You amaze me. I wish my girlfriend was more  
>> like
>> you, then I'd never be bored. An endless source of simple amusements.
>> :-))))
>> There should be a law that forbids any data structure to call itself
>> "database" until it can meet at least 2nf (out of 5, well 8 really..)
>>
>> In the mean time here's some light reading
>> http://en.wikipedia.org/wiki/Database_normalization
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html