We use Sybase IQ where I work, and other than rebooting it every few days, frequent crashes, and slow running queries, it's pretty good.
We are right now offloading a huge reporting database into SQL Server because our queries run about 6x faster.
This is a star-schema data warehouse with a few TB of data.
The big difference is that SQL Server supports partitioning.
You can rent the solar panels from http://renu.citizenre.com/ and just pay them for the electricity they generate at the same rate you're paying the utility company.
I've signed up but panels won't be available until September. Also, you have to put down a $500 security deposit and you'll probably want to check with your homeowner's insurance to see what you need to do to protect them.
I'm only sort of kidding here - I think frameworks are great for people who don't have strong OO design background and/or don't fully understand the MVC pattern, or for people who work on a team where some people meet these criteria. A framework forces everyone to "stay in bounds."
But if you (and everyone on your team) do understand these things, then I'm personally an advocate for just using an OO language (PHP, Java, whatever) and making sure your class design follows the MVC pattern.
ActiveRecord (and other stuff like it) are nice to get a prototype page up, but it's not hard to write classes that can update/insert themselves into a database (assuming you use a solid OO design). By the time the pages and objects get more complicated, the amount of control you'll have by doing it yourself will make up for the time lost that an ORM tool saved you in the beginning. Adding complex business logic to the queries, optimizing the queries, and just general maintenance will be easier if you've done it yourself (again, assuming it was done with a solid OO design).
I'm not trying to make a blanket statement here, different projects will have different needs. I have decided against using a framework in one project I'm working on right now, and these are some of the main reasons.
In other projects, I've been a big advocate for a framework.
If the battery packs can have a standardized size and interface, I can see refilling stations popping up that just do a quick swap of your battery pack for a fully charged one.
Of course, since battery packs degrade with age, there would have to be a way to measure this to make sure you're not paying full price for a fully charged battery pack that is only holding 50% of the energy you're paying for.
This would also work out nice because the refilling stations would be the ones paying the cost for new battery packs when old ones wear out, and the price could be amortized over the lifetime of the batteries instead of a painful one-time charge to a consumer replacing a battery pack after 5-10 years.
What we're doing is extracting data from the warehouse and then using custom Java code to process that data. We're finding this to be much faster and easier than any SQL based approach (such as stored procedures and ETL tools).
Databases already have the ability to change storage engines as long as they support SQL. The reason my company shuns the database for many specific tasks is that SQL is ill-suited to perform many types of transformations, calculations, and aggregations on data. What may take many pages of SQL (and many temp tables) in a stored proc can be written in a simple Java class and will perform much better, as well as being easier to maintain.
A lot of our processing goes like this
Raw data from database (simple select queries, which are very fast) -> flat files -> custom Java code -> reporting engine or another database.
The speedup over using stored procs or SQL based ETL tools ranges between a factor of 10 and a factor of 100.
MDX is a better language than SQL for a lot of purposes, but not all.
In our company, we use the database mostly as a warehouse. Our daily processing is done via flat files and Java code. It's just much, much, much faster that way and easier to maintain. I think we're kind of a special case though.
I use Cobian Backup to backup some Windows data via FTP to an offsite server, but I'm not really happy with it. It was a real pain playing with the settings until the backups completed successfully. They would hang after a while and it took some trial and error to get them working, but my backup tasks are never marked as finished even though I can check the backup and see that they really are done. Cobian shows that the backup is still in progress until I reboot! The cancel button doesn't even work!
I assume it works well for other people though, and setting up the tasks and their schedules is pretty easy and very flexible.
Actually, compression can improve performance. Often disk I/O can slow you down more than the extra CPU work to compress/decompress.
I have written some flat-file processing code at my work and it runs much faster reading from and writing to zipped text files instead of uncompressed text files. The space savings are just a bonus.
I can think of a few things: - Microsoft Analysis Services: IMO, better than Hyperion, Cognos, etc as of 2005. And like it or not, SQL Server 2005 is a good RDBMS for Enterprise level use. This release of SQL Server also brings data mining to the masses. The only thing that really sucks about the entire SQL Server 2005 release is that you have to run it on a Windows OS! - Microsoft Visual Studio: I know, everyone has their favorites, but it really is a very good IDE. MS has been making good IDEs probably longer than anybody (well, except emacs). Again, the biggest drawback is that it only runs on a Windows OS. - MSDN: Best web reference (only works with IE though).
His only point is not the actual quantifiable values of the numbers, but rather how they change with load. If you were to plot the different techniques on a graph, you would hopefully see a linear line for the streaming, whereas the other techniques would have either a steeper slope or an exponential curve.
It's the slope/shape of the line that's important when analyzing scalability, not the actual numbers.
... and the author didn't recommend this technique for small transactions. In fact, he specifically said don't do it for those types of requests.
Making a new connection for every VERY LARGE request might make sense depending on the scenario. If it takes 0.25 secs to login and get a connection, and 3 minutes for the database to execute a query and return 10,000 rows, then who cares about the 0.25 seconds?
I think you're missing the point of the article. Whether he is using EJBs or just an EJB-like pattern, the analysis of the algorithms' scalability is the same.
It's common sense, but a lot of people who are trained in EJB development always do things the same way without really thinking about what's actually happening behind the scenes. This article makes a good case for using a database cursor and "streaming" objects to the web page as you read them, as opposed to letting a bean read the entire result set and then creating the web page.
It absolutely will scale better for large result sets and large numbers of users.
MS gives Novell 440 million. Novell gives MS 40 million for "protection."
So really, MS gives Novell 400 million, and in return Novell inserts some MS intellectual property into Linux?
The people you work with and the challenge/variety of your projects will probably play a much, much, much larger role in your work satisfaction than what programming language you're using.
They track this data already based on time. That's how they could provide data on the Super Bowl wardrobe malfunction - because they knew exactly when and on what channel that happened.
I doubt TiVo knows exactly what time commercials are telecast (and on which stations). They are probably pulling in that data from an external source. Then they can match it up with their TiVo data to find out which commercials have been skipped and how much they've been skipped.
You say, "good product to support bad software," I say "another tool to use."
If you have a particular problem to solve, and you could solve it with another software release or a virtual server, sometimes it makes more sense just to use virtualization.
It's also handy for load balancing in the sense that you don't want a particular process consuming too many of the machines resources. Virtualization is an easy way to partition a big server's resources. Sure, you could also handle this by increasing the complexity of the software, but why?
I agree. Opening ports shouldn't be a big issue or barrier to adoption. This is what ports are for - IPC/distributed computing! Firewalls allow ports to be opened for this very reason. It's easy and simple to do in any environment. Now why the hell should we drop a pretty good technology just because some network engineer is too lazy or stubborn to manage some ports?
Re:What a ridiculous trend... CORBA to WebServices
on
The Rise and Fall of Corba
·
· Score: 2, Interesting
Have you ever developed web services? For the most part, it's even more complex. WSDL is more complex than IDL, for sure. Interfaces in WSDL often have to be awkward because they lack object orientedness. Callbacks are a real pain in the neck using SOAP. Performance sucks. Large objects suck. And as someone else said, SOAP is struggling to provide standards and features that were mature in CORBA for years.
There are some environments, such as.NET, that make developing web services a breeze.
The author has some good points on why we as an industry moved away from CORBA, but SOAP and web services are even worse in my opinion.
All of the presentation stuff should be done using CSS these days. The HTML should be purely descriptive of the content, not the presentation. Therefore, HTML is fine inside your PHP. CSS is not.
That, in my opinion, is where the line is drawn - between the HTML and the CSS.
There may be other benefits in some cases to removing HTML from certain PHP classes/functions, such as reusability.
Such a predictable response. Modern language compilers provide a very useful layer of abstraction (readability, maintenance, portability, more rapid development, etc). I'm just not sure I see the usefulness in this particular abstraction layer.
I haven't tried this yet, but I'm wary of any Java->JavaScript/HTML compiler. Inevitably, there will be something you need to work around in the JS/HTML but can't.
It's just an abstraction layer which may be nice for simple things that don't need much customization but in reality, it will end up being something that gets in the way and you have to hack some workarounds to get exactly what you want.
Really, how hard is it to code JavaScript and HTML? AJAX isn't braing surgery or rocket science. Most browser incompatabilities are well-known and there are published workarounds that are easy to find if you can't figure them out yourself.
I'd rather hand code my HTML/CSS so I get exactly what I want (and nothing extra). I hate auto-generated HTML.
Slashdot Mirror
We use Sybase IQ where I work, and other than rebooting it every few days, frequent crashes, and slow running queries, it's pretty good. We are right now offloading a huge reporting database into SQL Server because our queries run about 6x faster. This is a star-schema data warehouse with a few TB of data. The big difference is that SQL Server supports partitioning.
You can rent the solar panels from http://renu.citizenre.com/ and just pay them for the electricity they generate at the same rate you're paying the utility company.
I've signed up but panels won't be available until September. Also, you have to put down a $500 security deposit and you'll probably want to check with your homeowner's insurance to see what you need to do to protect them.
I'm only sort of kidding here - I think frameworks are great for people who don't have strong OO design background and/or don't fully understand the MVC pattern, or for people who work on a team where some people meet these criteria. A framework forces everyone to "stay in bounds." But if you (and everyone on your team) do understand these things, then I'm personally an advocate for just using an OO language (PHP, Java, whatever) and making sure your class design follows the MVC pattern. ActiveRecord (and other stuff like it) are nice to get a prototype page up, but it's not hard to write classes that can update/insert themselves into a database (assuming you use a solid OO design). By the time the pages and objects get more complicated, the amount of control you'll have by doing it yourself will make up for the time lost that an ORM tool saved you in the beginning. Adding complex business logic to the queries, optimizing the queries, and just general maintenance will be easier if you've done it yourself (again, assuming it was done with a solid OO design). I'm not trying to make a blanket statement here, different projects will have different needs. I have decided against using a framework in one project I'm working on right now, and these are some of the main reasons. In other projects, I've been a big advocate for a framework.
Hopefully, as ice thaws and more land is uncovered, there will be more room for plants to grow to clean CO2 out of the air.
If the battery packs can have a standardized size and interface, I can see refilling stations popping up that just do a quick swap of your battery pack for a fully charged one.
Of course, since battery packs degrade with age, there would have to be a way to measure this to make sure you're not paying full price for a fully charged battery pack that is only holding 50% of the energy you're paying for.
This would also work out nice because the refilling stations would be the ones paying the cost for new battery packs when old ones wear out, and the price could be amortized over the lifetime of the batteries instead of a painful one-time charge to a consumer replacing a battery pack after 5-10 years.
We don't have Java inside stored procedures.
What we're doing is extracting data from the warehouse and then using custom Java code to process that data. We're finding this to be much faster and easier than any SQL based approach (such as stored procedures and ETL tools).
Databases already have the ability to change storage engines as long as they support SQL. The reason my company shuns the database for many specific tasks is that SQL is ill-suited to perform many types of transformations, calculations, and aggregations on data. What may take many pages of SQL (and many temp tables) in a stored proc can be written in a simple Java class and will perform much better, as well as being easier to maintain. A lot of our processing goes like this Raw data from database (simple select queries, which are very fast) -> flat files -> custom Java code -> reporting engine or another database. The speedup over using stored procs or SQL based ETL tools ranges between a factor of 10 and a factor of 100. MDX is a better language than SQL for a lot of purposes, but not all.
In our company, we use the database mostly as a warehouse. Our daily processing is done via flat files and Java code. It's just much, much, much faster that way and easier to maintain. I think we're kind of a special case though.
I use Cobian Backup to backup some Windows data via FTP to an offsite server, but I'm not really happy with it. It was a real pain playing with the settings until the backups completed successfully. They would hang after a while and it took some trial and error to get them working, but my backup tasks are never marked as finished even though I can check the backup and see that they really are done. Cobian shows that the backup is still in progress until I reboot! The cancel button doesn't even work! I assume it works well for other people though, and setting up the tasks and their schedules is pretty easy and very flexible.
Actually, compression can improve performance. Often disk I/O can slow you down more than the extra CPU work to compress/decompress. I have written some flat-file processing code at my work and it runs much faster reading from and writing to zipped text files instead of uncompressed text files. The space savings are just a bonus.
I can think of a few things:
- Microsoft Analysis Services: IMO, better than Hyperion, Cognos, etc as of 2005. And like it or not, SQL Server 2005 is a good RDBMS for Enterprise level use. This release of SQL Server also brings data mining to the masses. The only thing that really sucks about the entire SQL Server 2005 release is that you have to run it on a Windows OS!
- Microsoft Visual Studio: I know, everyone has their favorites, but it really is a very good IDE. MS has been making good IDEs probably longer than anybody (well, except emacs). Again, the biggest drawback is that it only runs on a Windows OS.
- MSDN: Best web reference (only works with IE though).
His only point is not the actual quantifiable values of the numbers, but rather how they change with load. If you were to plot the different techniques on a graph, you would hopefully see a linear line for the streaming, whereas the other techniques would have either a steeper slope or an exponential curve. It's the slope/shape of the line that's important when analyzing scalability, not the actual numbers.
... and the author didn't recommend this technique for small transactions. In fact, he specifically said don't do it for those types of requests. Making a new connection for every VERY LARGE request might make sense depending on the scenario. If it takes 0.25 secs to login and get a connection, and 3 minutes for the database to execute a query and return 10,000 rows, then who cares about the 0.25 seconds?
I think you're missing the point of the article. Whether he is using EJBs or just an EJB-like pattern, the analysis of the algorithms' scalability is the same. It's common sense, but a lot of people who are trained in EJB development always do things the same way without really thinking about what's actually happening behind the scenes. This article makes a good case for using a database cursor and "streaming" objects to the web page as you read them, as opposed to letting a bean read the entire result set and then creating the web page. It absolutely will scale better for large result sets and large numbers of users.
MS gives Novell 440 million. Novell gives MS 40 million for "protection." So really, MS gives Novell 400 million, and in return Novell inserts some MS intellectual property into Linux?
The people you work with and the challenge/variety of your projects will probably play a much, much, much larger role in your work satisfaction than what programming language you're using.
... and everything worked fine. There was a paper printout, a review screen, and everything I touched was checked correctly the first time.
After reading your post, I think a return to horses makes the most sense!
They track this data already based on time. That's how they could provide data on the Super Bowl wardrobe malfunction - because they knew exactly when and on what channel that happened.
I doubt TiVo knows exactly what time commercials are telecast (and on which stations). They are probably pulling in that data from an external source. Then they can match it up with their TiVo data to find out which commercials have been skipped and how much they've been skipped.
You say, "good product to support bad software," I say "another tool to use."
If you have a particular problem to solve, and you could solve it with another software release or a virtual server, sometimes it makes more sense just to use virtualization.
It's also handy for load balancing in the sense that you don't want a particular process consuming too many of the machines resources. Virtualization is an easy way to partition a big server's resources. Sure, you could also handle this by increasing the complexity of the software, but why?
I agree. Opening ports shouldn't be a big issue or barrier to adoption. This is what ports are for - IPC/distributed computing! Firewalls allow ports to be opened for this very reason. It's easy and simple to do in any environment. Now why the hell should we drop a pretty good technology just because some network engineer is too lazy or stubborn to manage some ports?
Have you ever developed web services? For the most part, it's even more complex. WSDL is more complex than IDL, for sure. Interfaces in WSDL often have to be awkward because they lack object orientedness. Callbacks are a real pain in the neck using SOAP. Performance sucks. Large objects suck. And as someone else said, SOAP is struggling to provide standards and features that were mature in CORBA for years.
.NET, that make developing web services a breeze.
There are some environments, such as
The author has some good points on why we as an industry moved away from CORBA, but SOAP and web services are even worse in my opinion.
All of the presentation stuff should be done using CSS these days. The HTML should be purely descriptive of the content, not the presentation. Therefore, HTML is fine inside your PHP. CSS is not.
That, in my opinion, is where the line is drawn - between the HTML and the CSS.
There may be other benefits in some cases to removing HTML from certain PHP classes/functions, such as reusability.
Such a predictable response. Modern language compilers provide a very useful layer of abstraction (readability, maintenance, portability, more rapid development, etc). I'm just not sure I see the usefulness in this particular abstraction layer.
I haven't tried this yet, but I'm wary of any Java->JavaScript/HTML compiler. Inevitably, there will be something you need to work around in the JS/HTML but can't.
It's just an abstraction layer which may be nice for simple things that don't need much customization but in reality, it will end up being something that gets in the way and you have to hack some workarounds to get exactly what you want.
Really, how hard is it to code JavaScript and HTML? AJAX isn't braing surgery or rocket science. Most browser incompatabilities are well-known and there are published workarounds that are easy to find if you can't figure them out yourself.
I'd rather hand code my HTML/CSS so I get exactly what I want (and nothing extra). I hate auto-generated HTML.