sql module and radgroup...

[Alan DeKok]

predrag balorda wrote:
> Well, read it, over and over again, until you do.

  A useful suggestion, I'm sure.

>>> 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

  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 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.

> 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.

>>> 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.

> 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...

  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'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.

> 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.