sql module and radgroup...
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
>> 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
>> 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
> 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!
>> 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
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
More information about the Freeradius-Devel