sql module and radgroup...

predrag balorda predrag.balorda at gmail.com
Fri Jul 9 19:43:25 CEST 2010


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




More information about the Freeradius-Devel mailing list