January 20, 2009 at 9:48 am
Jason Shadonix (1/16/2009)
Yes and no.I used to work for a not-for-profit company that had SQL Server and Access, but no decent devleopment tools. (Couldn't/wouldn't pay for decent MS tools, so had to do open source stuff for the most part).
I wrote a lot of Access Data Project (ADP) applications that actually worked out very well, even for pretty good sized databases. It worked by having all of the forms/business logic in Access, but the actual database being on SQL server.
It's a suprisingly good development environmentm and you can get a pretty powerful application (and reports) written pretty quickly.
I got my start as a DBA when I was a salesperson and built an Access database to keep track of my customers and their orders. (No file cabinets or anything! It was just PostIts till I built that database.)
Eventually ended up as an Access ADP on top of SQL Server 2000, and it was a pretty good solution for that business. I've had other ex-employees tell me they miss it and were spoiled by it.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 21, 2009 at 8:33 am
Jeff Moden (1/16/2009)
hb21l6 (1/16/2009)
It would appear that I have made a bit of a stir with this question. Sorry all,I think I’ll just stick at my MS SQL. Should be ready to sit my first exam soon. :O)
Oh no... don't be sorry at all. That type of question is exactly what forums are all about. Some get a bit more heated up than the rest, but where else could anyone go and get such a wide diversity of mostly thoughful answers? Nah... you did good.
I agree with Jeff, this is definitely a good discussion and timely for me. I plan for forward a link to this thread a my manager.
January 21, 2009 at 11:51 pm
Gift Peddie (1/18/2009)
Access and VFP are things Microsoft sells as database both are not relational.
SQL Server isn't relational either but more to the point Access and VFP are application development tools whereas SQL Server is a DBMS.
No-one's said much about the Oracle features-set compared to SQL Server. Oracle has features that SQL Server doesn't, such as RAC, Flashback, some OLAP functions, in-memory DB and many more storage, partitioning and indexing options than SQL Server. Microsoft has been catching-up with Oracle since SQL Server 7.0 but they are still a long way behind in some areas (the fact that SQL Server still has only B-Tree indexes is pretty disappointing for example).
Oracle's most important differentiator and advantage is that it runs on a range of OSs whereas SQL Server is Windows-only.
January 22, 2009 at 8:57 am
(SQL Server isn't relational either but more to the point Access and VFP are application development tools whereas SQL Server is a DBMS.)
Hi David,
The people who use Access and VPF don't see these as only application development tools because VPF users thinks it does Reports VPF reports are not BI grade reports like SSRS or Crystal reports creates. Access comes with funny aggregate functions and DRI wizard which users expect in SQL Server.
SQL Server is RDBMS so it is relational just as Oracle, IBM, Sybase and MySQL __level of ANSI SQL implementation varies. I still have problem with Oracle Number data type which is a bucket for all numeric data.
(Oracle's most important differentiator and advantage is that it runs on a range of OSs whereas SQL Server is Windows-only.)
This is a problem but Microsoft have made changes in 2008 on the relational end that Windows security is optional.
Kind regards,
Gift Peddie
January 22, 2009 at 7:15 pm
So! Anybody wanna talk about all the companies that use spreadsheets like databases? I'll start... I hate them all. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2009 at 12:00 pm
Jeff Moden (1/22/2009)
So! Anybody wanna talk about all the companies that use spreadsheets like databases? I'll start... I hate them all. 😛
I cannot possibly agree more. With that said, I suspect virtually everyone on these forums is an IT professional, lots of small business have 0 IT personell at all. For them, developing a full database solution (or even finding out what those words really mean) may be beyond their ability, but using spreadsheets is not. Once a company gets large enough to have any IT personnel at all they would be wise to stop the practice.
---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
January 23, 2009 at 12:33 pm
timothyawiseman (1/23/2009)
Jeff Moden (1/22/2009)
So! Anybody wanna talk about all the companies that use spreadsheets like databases? I'll start... I hate them all. 😛I cannot possibly agree more. With that said, I suspect virtually everyone on these forums is an IT professional, lots of small business have 0 IT personell at all. For them, developing a full database solution (or even finding out what those words really mean) may be beyond their ability, but using spreadsheets is not. Once a company gets large enough to have any IT personnel at all they would be wise to stop the practice.
When I first got into building a database, just finding definitions for some of the terms was like walking through fire.
"Relational": Of or about relational databases or relations
"Relational Database": A database that uses relations
"Relation": Part of a relational database
That's one kind of definition I was able to find online, in books, etc. The others looked more like this:
"A relation is defined as a set of tuples that have the same attributes. A tuple usually represents an object and information about that object. Objects are typically physical objects or concepts. The relational model specifies that the tuples of a relation have no specific order and that the tuples, in turn, impose no order on the attributes. Applications access data by specifying queries, which use operations such as select to identify tuples, project to identify attributes, and join to combine relations. Relations can be modified using the insert, delete, and update operators. New tuples can supply explicit values or be derived from a query. Similarly, queries identify tuples for updating or deleting." (From Wikipedia)
Yes, that definition is quite clear to me now, but 8 years ago, when I was a salesperson, it might as well have been written in Swahili.
It took me a LONG time to find something in between those two that made it clear enough to be comprehensible.
So, I don't blame people who try to use Excel for data storage. Try to help them understand that there are better ways to do that? Yes! Blame them? No.
Far too much material about database use and development is written from the viewpoint of people who already know, far too little is written for people who aren't already experts. Books Online (and MSDN) are guilty of this all over the place. If they are intended pretty much to document, and to refresh the memory of skilled pros, they're fine. If they're meant to be a primary source of information to learn from, they fail miserably.
Edit: And don't even get me started on how useless the "For Dummies" book on SQL Server was! If you want to be a script kiddie and query a few things, it might get you started, but if you need to build a database that will actually satisfy a business need, just forget it on that one!
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 23, 2009 at 6:15 pm
timothyawiseman (1/23/2009)
Jeff Moden (1/22/2009)
So! Anybody wanna talk about all the companies that use spreadsheets like databases? I'll start... I hate them all. 😛I cannot possibly agree more. With that said, I suspect virtually everyone on these forums is an IT professional, lots of small business have 0 IT personell at all. For them, developing a full database solution (or even finding out what those words really mean) may be beyond their ability, but using spreadsheets is not. Once a company gets large enough to have any IT personnel at all they would be wise to stop the practice.
Oh no... I understand the Mom and Pop shops doing the spreadsheet thing... I'm talking about some BIG companies (whose names I won't mention 'cause I don't wanna take a chance at getting sued for all my pork chops).
--Jeff Moden
Change is inevitable... Change for the better is not.
January 24, 2009 at 7:23 pm
Jeff Moden (1/23/2009)
Oh no... I understand the Mom and Pop shops doing the spreadsheet thing... I'm talking about some BIG companies (whose names I won't mention 'cause I don't wanna take a chance at getting sued for all my pork chops).
Yes, I cannot understand why a big company would do that.
---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
January 25, 2009 at 4:01 pm
Unfortunately, the reason why some very large companies end up dong this is that someone comes along and says he we need to represent x data y way... Or more likely some "hot shot" new person shows up who actually can use excel for more than entering a bit of data and using the autosum feature. They see things being kept on paper or by hand and say, hey I can make that more efficient with excel. They do so and everyone is happy.
No one talks about automating this with IT, or project development or whatever group is in charge of such things at your company. Perhaps because no one thinks of it, or maybe it's because IT's policies and procedures are so obtuse to the "normal" working stiff, or that they'd be letting go of the department's control, or a variety of other reasons which make no sense when actually thought through, but at the end of the day a process is developed in excel because it's easy for the end user.
It's perpetuated because "that's the way we've always done it", until such time as someone from IT has to create reports on this data, or worse recover missing info because it was never backed up and just kept on someone's desktop. When someone from IT looks at it and says, we could do this better and here's how, now it becomes our job to "massage" the data into some database or other and design a process around it, and say, "Why the !#@$ were they doing it that way! Don't they know we could have done this right from the get-go if only they'd asked us?"
-Luke.
January 26, 2009 at 7:50 am
One of the problems I've seen that causes Excel-as-database solutions is where IT has some byzantine policy for software specification, and it's complex and painful enough that nobody wants to do it. Most often, this is caused both by IT and management.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 26, 2009 at 7:58 am
GSquared (1/26/2009)
One of the problems I've seen that causes Excel-as-database solutions is where IT has some byzantine policy for software specification, and it's complex and painful enough that nobody wants to do it. Most often, this is caused both by IT and management.
I've seen that a lot as well. Lots of IT departments forget that their company needs to actually do business. They get too worked up about designing something that will solve problems that don't yet exist and end up turning a design for a car into a design for a spaceship. Then some clever end-user builds a bicycle to get by for awhile and the company decides not to spend the money on the spaceship because "the bicycle works fine".
I used to blame the guys that created the spreadsheet, but these days, I like to spread that blame out a lot more.
January 26, 2009 at 11:21 am
Luke L (1/25/2009)
Unfortunately, the reason why some very large companies end up dong this is that someone comes along and says he we need to represent x data y way... Or more likely some "hot shot" new person shows up who actually can use excel for more than entering a bit of data and using the autosum feature. They see things being kept on paper or by hand and say, hey I can make that more efficient with excel. They do so and everyone is happy.No one talks about automating this with IT, or project development or whatever group is in charge of such things at your company. Perhaps because no one thinks of it, or maybe it's because IT's policies and procedures are so obtuse to the "normal" working stiff, or that they'd be letting go of the department's control, or a variety of other reasons which make no sense when actually thought through, but at the end of the day a process is developed in excel because it's easy for the end user.
It's perpetuated because "that's the way we've always done it", until such time as someone from IT has to create reports on this data, or worse recover missing info because it was never backed up and just kept on someone's desktop. When someone from IT looks at it and says, we could do this better and here's how, now it becomes our job to "massage" the data into some database or other and design a process around it, and say, "Why the !#@$ were they doing it that way! Don't they know we could have done this right from the get-go if only they'd asked us?"
-Luke.
The one's I'm talking about were actually designed by the nubs in IT! For these large companies that I've had the extreme displeasure of working with, the bloody spreadsheet is provided for all customer downloads regardless of type. I'm much rather poke an API and then have my file show up in a decent delimited or fixed length format than the spreadsheet like (multiple headers, foots, etc, etc) garbage they currently send. Most of it is import resistant and requires a least some minor preprocessing to get it into a database table.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 27, 2009 at 9:34 am
I've seen lots of XLS stuff done, heck I used to built some Lotus 123 stuff like this, not because you don't want a proper app, not because you don't like IT to build things, but because you want it done today. You want to analyze some data, get it into one place you can see it, and work with it.
I've seen many people do that, get those Excel apps written with some macros to move data around to get their job done. And then they modify them as needed.
I'm OK with that. I'd like to see a sheet with structured data in the background so eventually we can suck it into a db and allow it to be used by others, back it up, or even move to a real app. I think it's a good way of prototyping, especially as people often don't know what they want. They have to mess wit it to figure out what works.
January 27, 2009 at 10:25 am
I am a developer using both Oracle and SQL Server. Even though they are relational database, it is very different to write PL/SQL and T-SQL. The SQL syntax is different in some cases, for example, SQL Sever uses 'CAST' or 'CONVERT' and Oracle uses 'TO_CHAR' or 'TO_DATE'.
I was an Oracle developer for a number of years before I started using SQL Server. Oracle uses cursor extensively and SQL Server is a 'no, no'. The SQL Server DBA threw back my first SQL Server stored procedure to me and yelled at me because I used cursor.
I used to work with a contractor that was very good with Oracle. Of course he used cursor all the time. My company used SQL Server. He wrote a stored procedure and took 26 hours to run.
Another thing to consider when choosing Oracle and SQL Server.
Viewing 15 posts - 46 through 60 (of 250 total)
You must be logged in to reply to this topic. Login to reply