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