[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SAGE] System Inventory
Gulfie wrote:
> On Wed, Nov 30, 2005 at 03:54:10PM -0600, Brian T. O'Neill wrote:
>
>>Quoting David Wolfskill (david@catwhisker.org) from :
>>
>>>So if that's perceived to be a concern, cobble up a CGI that does
>>>the above and point 'em to a Web page to exercise it.
>>
>>Ofcourse, that then looks the same to the end user of the data as if it
>>was in a database, and they'll then expect the same type of information
>>queries they'd expect if they knew it was in a SQL database, which was
>>Gulfie's inital problem.
>
>
> My problem is figureing out what is there, and finding out when it
> changes.
SQL triggers are great at helping keep track of changes by automatically
time-stamping such events. It then becomes trivial to ask for all data
that has changed since 'x'.
>
>
>>I find it's much easier to quickly add in the
>>"reports" that management wants when the data is in a SQL database then
>>munging text files, especially when you have a very diverse number of
>>platforms. It's easier imho to do "SELECT hostname from table where
>>OS='Solaris 8' AND IP LIKE '10.0.0.%' AND last_update = 'today'" which
>>will give me all Solaris 8 boxes on network 10.0.0 that were live on the
>>network as of the last database update.
>
>
>>"SELECT hostname from table where OS='Solaris 8' AND IP LIKE '10.0.0.%' AND last_update = 'today'"
>
>
> But this assumes that all this information is stuffed into the schema well, and for this case it seems to be. But maybe this example may just show up how the (realational) databases fail in my eyes (for this purpoes).
>
> The table seems to have a colum called IP. How does it deal with machiens that have more than one IP? More than one interface? Or both an IPv4 and IPv6 addresses? Maybe '%10.0.0.%' or maybe add many to one relation for IPs.
>
> OS is also kind a a funny thing. What OS is that Sun over there? It's SunOS, SunOS 5.80 and it's 'Solaris 8', and it changes depending on who is asking the question and the context
> that question is in.
>
>
> Often times getting data into 'the database' strips out and normalizes a lot of
> good information away. When it is gone, it's gone. When new wierd data shows up in the
> flat files you'll have to modify the reporting tools, but you won't have to do a complete
> schema change (which never gets done because of cost).
You don't have to delete any data, but you do have to think a bit more
about the data you're gathering. IMO, this is a good thing, since you're
more likely to gather the useful data that you need.
If you target your database at a single report, yes, you can end up
throwing away useful data. If you sit back and think about what to do
with all of that data as you're gathering it, you may actually go back
and get *more* data because you start thinking about how the data can be
used.
>
> That being said, there are still lots of good places for both databases, and hardware inventory databases. If there are very large collections of items, all with well defined
> or definable charicteristics, they'r great. Keeping track of all of Wall Marts cash registers via flat file would be virgeing on nuts. I personaly have found that unix/buisness enviroments are much more varraible than most database schemas are ready to take.
A well planned database can take all of these things into account (e.g.,
multiple interfaces, hostname aliases, etc.). We use an in-house DB to
do exactly these kinds of things, complete with a fancy web front end
and report builder.
However, it is not a small effort to set up. I do prefer SQL-accessible
data for these kinds of things, though. If you are reasonably careful
about how you store the data, and think about extensibility as you go,
you can make great 'what if?' engines in a relatively short period of
time. We use Oracle for the big, multiuser databases. I often use SQLite
for personal, fast, what-if data stores.
>
>
> -gulfie
>
>
> P.S. A big flat file tree is a great place to start from when loading data into a database.
>
>
If you load it directly into a database you have a chance of parsing it
and finding your data shortcomings while still gathering the data. If
you just dump it all in flat files, you can find that you either didn't
collect the right data, or that the job of re-parsing the data is huge.
When we changed from the big file tree to Oracle for system information
gathering we just left the old data behind.
I spend a lot of time creating and using databases, and I know that not
everyone does. Sometimes it feels like "data is my life". (:-) Others
may not be as comfortable in that environment, and can find SQL
daunting, especially if they only use it occasionally, and I certainly
would not suggest this kind of data gathering as anyone's first exposure
to relational databases.
- Richard