sql module and radgroup...

Gabriel Blanchard gabe at teksavvy.ca
Fri Jul 9 19:47:34 CEST 2010

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

More information about the Freeradius-Devel mailing list