Slashdot Mirror

Such things do exist--there are some free resources online as well as books that one can buy.

Free data model collections:
http://www.databasedev.co.uk/data_models.html
http://www.databaseanswers.org/data_models/

Books:
A guy named Len Silverston has made this his niche--he's written these books:
"The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises"
"The Data Model Resource Book, Vol. 2: A Library of Data Models for Specific Industries"

More about them on Amazon:
http://www.amazon.com/s?ie=UTF8&search-type=ss&ind ex=books&field-author=Len%20Silverston&page=1
Or check this out:
http://www.univdata.com/book.htm (univdata.com is Silverston's company).

Another book (Silverston co-authored): "The Data Model Resource Book: A Library of Logical Data and Data Warehouse Designs " http://www.amazon.com/Data-Model-Resource-Book-War ehouse/dp/0471153648

If you want a free taste of what Silverston is about, here's an article he did with a data model for clickstream analysis:
http://www.dmreview.com/article_sub.cfm?articleId= 4479
And this is a more general article on universal data models that he wrote:
http://www.tdan.com/i010fe04.htm

The 2003 article Is the Portal Dead? discusses Gartner's announcement that "the portal is dead, long live the portal." And more recently, Portals are Dead reiterates that. But of course, there's plenty more about the death of the portal.

For coverage on OLAP and more generally, business intelligence, visit The Data Warehousing Institute. In addition to their online articles, you can subscribe to a weekly email newsletter which provides timely info about BI and OLAP developments. If you really want to get into it, they have some hands-on courses offered fairly regularly around the US. I haven't taken any of them, but based on the course outline the OLAP course looks pretty informative and I think TDWI has a good reputation.

Finally, you might check out DM Review's website as they have some good content on data warehousing, BI and OLAP as well.

IMO you need a clue bat application.

Here, use mine.

1. As far as I know, Sun tried to license NFS. Failed. For various reasons.

Sun made the NFS protocols available in several RFCs. ( RFC 3010 NFS version 4 Protocol, RFC 1094 NFS: Network File System Protocol Specification, RFC 1813 NFS Version 3 Protocol Specification. )

Anyone was free to do a clean implementation based on the RFC, or license Sun's code. Apparently this was such a failure that NFS is used by: Sun, IBM, HP, SCO, SGI, Apple, Microsoft, Hummingbird, *Linux, *BSD, ...

Do not try to pull that "give to the community crap" at least as far as NFS is concerned.

You are either uninformed or trolling. Sun is paying the U of Michigan to port NFSv4 to Linux and OpenBSD. NFSv4 porting project

2. Solaris (not SunOS) NFS support until 2.6 was crap.

Hmmm. I was part of a team running a large engineering site using Solaris 2.5.1 and HP/UX 10.20. Solaris 2.5.1 without patches did suck. But with a reasonable patch set (you did patch, right? Even once at installation?) 2.5.1 was very solid (in my opinin, much more so than HP/UX, especially under version 3 - shudder).

Many patchlevels even as late as 2.5.1 had quite a few data corruptions bugs. As a result most old non-academic installations actually used NetAppliance when they needed NFS.

Network Appliance was founded in 1992, shipped their first product in 1993 (a 7Gb appliance), and in 1995 their total revenue was $45million. Even given their rapid growth, there is no way that "most old non-academic installations" were using Network Appliance for their NFS needs in the Solaris 2.5.1 timeframe. Network appliance history

Good grief, Sun shipped 1.6 petabytes of fibre-channel storage alone in 1998. Sun ships 1.6PB

3. I had to be a design authotity on something like 100+ Netra T1s with Solaris running the most elementary services like DNS, news, mail, etc. None of them running more then one service so they were not even loaded.

Its not the number of services that run, its how heavily they are used. DNS isn't likely to be big load, but it could be as you move up the ISP food chain; news could definitely be a heavy load depending on your feed; mail - depends. I'm also curious, if your servers "were not even loaded," why did you use so many as the "design authority?"

And frankly I have not seen so many hardware failures and memory leaks in the core OS anytime before and anytime after.

Hardware - Maybe you had a bad batch, a lemon model, just plain bad luck. I've generally had good experience with Sun kit.
Core OS - You were following that best practice known as patching your systems, right?

most linux kernels in the 2.3.x and 2.5.x series were more reliable.

Linux NFS protocol support has generally been both limited and inferior to Solaris. (Little surprise - Sun invented it.) Linux also had many problems with stability and corruption prior to 2.2.17. It has greatly improved since then, but is still limited in terms of full protocol support. Since Sun is paying for the port of NFSv4 to Linux, it will no doubt continue to improve. As to the kernel in general, the Linux kernel today isn't fully the equal of Solaris. If you want to assert that it was 4 years ago, I don't think that you are making judgements based upon facts.

4. If you have created a website that needs one 100+ CPUs box instead of having the load spread across several redundant systems you should be fired on the spot.

Strawman/flamebait. Read the post. It didn't say one box with 100+ CPUs, it said "When you want to run a giant website with 100's of CPU's." In other words, a site like you claim to have designed.

IMO you need a clue bat application.

Are you done with the clue bat yet?

MySQL is not stable enough for a real 24x7 web service.

As in most things there are a variety of ways of looking at it. I found an intereseting article on the subject here.

I think it's clear from this thread that Access just isn't designed to run your enterprise. At best it's for non-DBA's to run simple databases for a relatively small number of users. So you're going to want to convert to a full-strength DBMS.

The real problem with converting from Access to a real DBMS like MySQL is not in converting the data itself, but in converting the stuff that's not the data. An MDB file is not just tables of data, but an all-encompassing file that contains tables, queries, forms, reports, macros, and VB modules, etc.

Any good database has rules which prevent invalid data from being entered. Just like any good program has good error handling to prevent any possible user entry from crashing the program. When you get bad data in your database the results are worse because you won't have any indication that your data is bad until it gets REALLY BAD, or painfully obvious. Not a good thing for business.

The problem with Access is that it doesn't have a tool for managing all of these rules. They are hidden, partly in the table definitions, partly on your forms, partly in macros and VB modules, and partly in the "Relationships" view. A business-class DBMS will have a tool to manage all these rules and mechanisms in one place. It will also allow flexible rules. For example, you can relax the rules in order to import a table that you know contains errors, then it can find all the errors, separate them or fix them, and start enforcing the rules for all new data entry. Access just isn't that sophisticated, and what controls it has, as I mentioned, are not all in one place.

The bottom line is that while it's easy to copy the data, it's very difficult to port over all of these hidden mechanisms that control data quality. That would require someone who knows a lot about Access, which I assume from your question that you are not (no offense). Your alternative is to copy the data to your favorite DBMS (MySQL, Oracle, or whatever), and then set up all your data integrity rules from scratch on the new system. That's probably what you'd end up doing anyway even if you could find all the hidden stuff in Access. It's also not a bad thing to do because it will force you to review and reconsider what data you are storing, how it is stored, how everything relates, what your data entry processes are, etc. That process is always a good thing. You would be wise to get help from a DBA.

If you feel confident hacking a DBMS without a DBA, then more power to ya, but you would be wise to proceed cautiously with your company's data. Build the tables and rules in your new DBMS and test it extensively with test data. Make sure it not only works, but also robustly handles errors and bad data entry before you stake your business on it. If you don't believe that it's important to address data integrity issues, take a look at the Y2K problem/response/expense and realize that you can have the same problems with ALL of your data, not just the dates.

If you aren't familiar with what data integrity/quality is, or how to maintain it, try the following links:

Database Central

DM Review

Best of Luck.