I'm only asking this because I'm finding as I get older, it becomes a much more frustrating part of my job.
How do you handle new versions of software, particularly software that coders and DBAs use on a regular basis? It seems that just when I've fleshed out SQL2005, SQL2008 will have come and gone and SQL2010 will be here. I've missed a whole iteration and this isn't endemic to coders and DBAs.
I'm never for upgrading just for the sake of upgrading so unless there is compelling functionality there, I tend to let it go. Somehow though, with software releases becoming more frequent, I can't help but feel that this is the wrong approach.
Edited to add:
I guess part of what I'm saying is that the release of newer versions hardly leaves enough time to become an expert in the previous version.
Rarely do these upgrades require a lot to be relearned. Actually, I would almost argue, that the amount to relearn is proportional to the amount of time between releases. So SQL Server 2000 to 2005 was 5 years, and quite a lot changed. 2005 to 2008, not much changed. 2008 to 2010, I'm guessing that there won't be a lot to learn. I think the trick is to keep on top of things. Because if you fall a few versions back, it can be a nightmare to catch up on things. Even if you just play around with it and don't use it in live projects, you are probably further ahead than a lot of people.
For server based software that needs to be stable, hitting "every release" isn't necessary a good thing. The only benefits you get from a new version are the new features (which if you don't need them, are not a concern) and finding all the incompatibilities now that might bite in the next release as well (on top of those included in the next release).
For this reason, we still support SQL 2000 on our primary product. We have ported and tested it against 2005 and 2008... but we are not using those new features. Too many clients are still running 2000. We are finally looking to cut support for 2000 when 2010 comes out, as 10 years seems a reasonable period, so our newest (not generally released, but in use with some clients) version uses some 2005 features.
As far as our development environment goes, we did move to 2005 and 2008 about a year after each release (when the first service packs were out). That is because the client isn't on the treadmill there, so we are more aggressive. The features in 2005 and 2008 were also compelling (I don't use Linq to SQL, but I love Linq to Objects ). We also do a lot of prototyping on newer versions of software, and keep our internal projects on newer software to keep up with the technologies features for planning and learning.
As far as becoming an expert, I think that with the scope of the technologies in question, nobody is an expert in the entire product. If you know all about the query optimization engine and how to wring the last bit of performance out of it, you are less likely to have spent a lot of time on the replication engine. Personally, I think you should sample everything, but at the end of the day you have to get to work: and your work will rarely require you to be an expert at everything. Just knowing that the features are there are enough so that the day you need them... you can quickly acquire a new skill and move on.
Related
It's been 10 years since this question was asked and answered here and I'd like to see what current thoughts are.
We have a third party app that we've supported for at least that long. It's an Access runtime application that connects to SQL Server and contains highly confidential data.
Some years ago we moved the database to an SQL Server running on Server Core. More recently we've been asked to run the first upgrade of the database schema in 6 years. The vendor provided upgrade package appears to be built using VB6 and won't run on the server. It also doesn't support running the updates remotely. We have a couple of ways that we can get it done but it has presented me with an opportunity to finally move on from what I think is not an enterprise product.
As part of that I've been asked why I think this product is so bad and, in my estimation, antiquated. My immediate internal response is that it's not a real application, it's Access. That's compounded by the fact that we're paying a pretty good bit for it and I think that there are better, more robust solutions now available that are also cheaper (I think in the end that's all that should matter).
That said I acknowledge that there my be some bias in my opinions on this particular app. Looking back at that old post a few things stand out.
I think there's a big difference between internally developed applications built this way and paid for solutions. Supporting an internally developed app written in Access may still have some positives. I don't think the positives pointed out in the top answer hold up when you're paying someone for it. The disadvantages are precisely what we're running in to.
Reporting isn't being done in Access. It's now mostly being done with outside tools. Most users want to see web based reporting.
A couple of the responses mentioned professional Access developers or this type of application being the COBOL of the 21st century. I think that's an apt description. I'm not sure professional Access developers still exist. How long should we try to maintain this and how long do we think the vendor will be able to?
I think the main mistake about Access is to consider it as a tool made for amateurs to develop applications. It can work this way, but keep in mind that amateur development will give you amateur applications, while professional development will give you professional results
Maybe this is the crux of my problem in particular. I'm not convinced that our application is 'professional'. It feels semi-pro if I'm generous. The VB6 updater is one clue and there are other components that have given me cause for concern over the years.
Fair or not, in my mind, most, if not all Access applications in the enterprise have these same issues. At the end of the day, the question is whether it serves the needs of the department using it.
Where does Access fit in the enterprise in 2019?
I have an asp.net-mvc3 website using nhibernate and SQL server. I have 2 web servers that are loaded balanced. This is a read heavy db (not so concerned with write performance), but as the queries are getting more and more complicated (lots of table joins) its slowing down performance considerably.
Based on comments I read , biggest win would be to put a distributed cache in front. I took a look for free options on windows that support nhibernate and I found NCache Express. I am going to obviously do a bunch of testing and playing around but I wanted to see (before i wasted a lot of time) if this express versions would limit me at all in terms of a workable solutions. I see the version comparisons here and I don't think I see any blockers but wanted to get feedback from anyone that has used NCache Express with nhibernate to see if there any issues.
Also, if there are alternative products suggestions for more efficiently solving this problem that would be great as well.
As mentioned before, you should first optimize your database, but of course you are already doing that.
I also work on a website with 2 servers and in the process of chosing a cache provider I've settled with MemcacheD. It is very robust and it is really simple to setup. NCache Expresse would work fine too, there is no mistery on it, but I recommend going with Memcache because NCache express has the 2 servers limit, so if you ever need to add an aditional node you'll have to change anyway.
Also, if your servers have Windows 2008 you should check Microsoft's AppFabric, it is very good.
Use this to evaluate what features do you require that NCache offers e.g. SQL dependencies and stuff
http://www.alachisoft.com/ncache/edition-comparison.html
Other than that i don't think you will required to upgrade
and regarding alternatives, i haven't used many so i cant say anything in this regard :)
PS: Replicated is great for read intensive applications and bad for write intensive.
You could try appfabric as the nhibernate 2nd level cache. You should run it on separate servers to your application nodes though.
Have you tried, Microsoft Velocity ?
http://msdn.microsoft.com/en-us/magazine/dd861287.aspx
I am looking for a Sybase PowerBuilder 8.0 setup. I found http://www.sybase.com/detail?id=1013232, but the all dowload links are broken.
Where can I download PowerBuilder 8?
You might ask Sybase, but I doubt they'd sell it to you. AFAIK, they haven't sold PB8 in about 8 years, and it hasn't been supported in 6 years. The current eval (11.5 at the time of this writing) is available off their main product page, if free is what you're after.
If it's PB8 you need, then you may be out of luck. Occasionally, you see an old copy sold on eBay, but I've had someone suggest to me that the license terms don't allow resale, so I'm not sure how legal this option is. (I'm no lawyer; maybe you'd want to ask that on "Litigation Overflow".) I'm sure I can leave the even less legal options up to your imagination.
Availability might be another reason to argue for an upgrade, beyond the technical reasons and new features, like operating system support. The PHBs won't like it, but then again, some live to aggravate PHBs; not you I'm sure.
Sorry, and good luck,
Terry
PB8? Sounds like you have to work on an existing system. The company that owns the code and is sponsoring the project surely has a legal license for you to use. It would need to provide you access to its copy if you don't have your own to work with.
Barring that, if you have access to the original code, it should be possible to migrate the application to a newer version of PB, although as Terry notes, PB8 is out of support and I'm not sure if there would be difficulties migrating. There would most certainly be some if the code features any special customizations or usage of now obsolete objects. In that case I can see how you would probably be best served by having PB8 to make adjustments noted by the migration assistant before completing the code conversion.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I'm trying to update a legacy app that does all its data storage in a hacked-together system of BDE Paradox files. The program works pretty well, under certain narrow conditions, but it has serious performance issues.
I'd like to try and improve things by updating to a better database system. What I need is a local database, preferably one where I can store the whole thing in one file instead of the current "one or more files per table" system. It has to support foreign-key relationships and table indexing, and it has to be able to return a result quickly from a query of a table with hundreds of thousands of elements.
This last one is important. The current system is indexed, but that doesn't seem to matter much. All the queries seem to run in O(N) time where N is the total size of the table, and it gets horrifically slow when the tables start to get large. I'm not really sure why, but that has to go away.
And it has to work under D2009 and later. Can anyone provide some recommendations?
Another vote here for embedded Firebird (and Firebird in general)!
I've just had an awesome experience porting an Interbase 6.0 app to embedded Firebird 1.5; after a short while reading the docs, the actual conversion took literally 20 minutes and now my app runs happily in Vista and Windows 7. If you don't need multi-user support then I'd seriously look at embedded Firebird (and if you do need multi-user support then why not look at regular Firebird anyway).
It's a single file for the db and a couple of small DLLs for the engine, and it's easy to deploy, maintain and backup. There are any number of tools to help during development and the technical support in the Delphi community for IB and Firebird is second-to-none.
The SQL support is excellent with constraints, triggers and stored procedures (we also have UDFs to help augment the language - DLLs which can be written in Delphi and used as in-line functions etc in your database. Very fast, very flexible).
Your final point about performance - well Interbase was always pretty snappy anyway, and my experience with embedded Firebird thus far is that it 'screams' - really, really impressed.
I've used this SQLite Wrapper with good success under D2009. I had it up and running in a matter of minutes. It has indexing and very low overhead. (This one is free and you don't need anything else besides the SQLite Dll)
There is also a commercial SQLite wrapper from Delphi Inspiration and the site says that they have a free for non-commercial and educational use license as well. I haven't used that one.
I've also used the Firebird embedded, but you then also need to have connectivity components to talk to it. I have IBObjects and that's what I use for both the server and embedded versions. I have tried other free Firebird database components but haven't really found any that I like or that I felt confident in.
[EDIT]
Since the majority of people are suggesting Firebird, here are some connectivity components for Firebird that I've tried in the past or that I've heard of:
Mercury Database Objects - Free/Opensource
IBObjects - Commercial (I've bought this one myself)
FIBPlus - Commercial
Firebirds ODBC Driver - Free/Opensource
ZeosLib - Free/Opensource
There's some good information available in this question - SQLite3 and Firebird Embedded seem to be good options.
Concurrency?
I used SQLite in one (non-Delphi) project and was very happy with it.
Otherwise, I think the embedded single-file DBMS of choice for Delphi seems to be Firebird.
Try Advantage Database, offered by Sybase (purchased from Extended Systems)
http://marketing.ianywhere.com/forms/ADS91-30-Day
It's free if you don't need client/server or internet functionality.
The downside is it's not 100% VCL, so the VCL included statically links to DLLs.
If the app ever needs to scale, you won't have to change databases again.
I would recommend using Postgresql as database, we use it in all projects that we work and tested it with over 4 million records in one table and worked pretty well.
Another option would be to use ADO and a microsoft access database. The only disadvantage is that the user has to have the Jet engine and MDAC installed... which most machines do. The advantage to this is that it makes upsizing to MSSQL easy. Just change the connection string to point to the SQL Server database, and make a few minor query changes.
I've used NexusDB for years and it's a small, reliable, flexible database. It's written in Delphi, comes with full source and can be compiled completely into your application (no DLLs to distribute) or run as a client server system.
It's hard to know whether it will meet your performance requirements but I haven't had a problem with my SQL query performance provided I was indexing the right fields. It's a one file per table product but don't let that stop you taking a look.
It's a commercial product but they offer a DCU only version that can only be used in single user/embedded applications for free.
I'm working at finishing up a conversion of a large application that has used BDE/Paradox for a local database and Oracle 8i for a remote db.
I'm using UniDAC from DevArt. That allows me a single component set (completely free from the old BDE) that can hit MSSQLServer as a local db and continue to hit Oracle as my remote. I have the prospect of being able to switch databases at either end much more easily now, just by changing providers.
I like this approach, and the components seem to be quite well done.
Jay
(D2007)
Postgresql is very good but it is a heavy machinery it is closer to oracle so you can do very heavy apps but a bit of a pain to maintain
Firebird is fantastic embedded or not
for connectivity in 2009 you can use FIB plus from devrace.com they have a trial version which just show a nag screen so if it not a commercial app it is ok.
else if it is a commercial app you can spend the 300 $ and buy it, I used also devart components for interbase/firebird and they are very good too
if you want free uses zeos but you get what you pay for http://sourceforge.net/projects/zeoslib/
SQL lite is not a single file and if it is multi user it sucks
I know this is not a programming question per se, but I wanted to get as much input from the SO community on a new project I hope to get started. The project is from being started from scratch and thus every decision for programming languages, databases, frameworks, platforms and what not are up in the air. I'm hoping to get your opinion on the matter, what you feel are the strengths and weaknesses of each option.
Database:
Currently I have the option of using MSSQL or MySQL. While I am leaning towards using MySQL because it is free and most probably has all the features I need. However, there is the possibility of having a lot of hierarchical data and the new hierarchical data type in MSSQL is quite appealing. Does it really simplify matters that much? Also MSSQL supports many more advanced SQL functions that may or may not be useful in the long run. While for development I can get access to Server 2008, multiple licenses as the development team grows and for production, are the costs justified?
Programming Languages:
The project will have a web based front end UI and a server based component that will do some heavy lifting.
For the web based UI, I was thinking of maybe doing Apache/IIS with PHP or IIS with ASP.Net in C#. I'd like to use a good framework to properly utilize good design patterns that should structure the code and development of the app. As well as make modifications in the long run easy to implement. I also want the GUI to look good and don't like the idea of buying .Net controls from component vendors. Instead I prefer the idea of using good CSS, and open sources like YUI and javascript to make the UI sleek.
For the server based component, I was thinking of using C#. I have no real development experience in C++ and I'd like good libraries and sufficient speed is good enough. However, while the web based UI and server based component is loosely coupled, there may be instances where the UI needs to communicate (call methods and what not) with the server based component and I want to pick languages/frameworks that will play nice with each other.
All suggestions on frameworks to incorporate are welcome.
Version Control:
I have had good experiences with SVN and a pretty bad experiences with TFS. I've never worked with GIT. Which do you think is better in terms of features as well as general developer familiarity. I want to pick something that other developers will know and not have trouble with.
I apologize if the questions are bit redundant or I'm not providing enough information or using bad terminology. I plan to edit and improve the question as I get feedback. Thanks!
EDIT:
Who: This would most probably be a startup formed of college students or junior developers. I want the project to utilize technologies that most people are familiar with or are easy to pick up.
What: I'd need hours and days to explain the solution. But in the end when you break it down, its a web based UI (think standard web app to just manage database data) that would be used to knowledgeable clients. The server based component would be very separate except for the fact that it should be able to communicate with the web app.
I can provide more information as required but I would appreciate an opportunity for users to answer and provide their ideas before you hastily close the question.
Obviously it depends a lot on specific requirements, but then again, even with those I probably wouldn't be able to tell for sure!
I've been working on a from-scratch project myself for a couple of months, and have generally found:
Choosing Microsoft for all the layers just goes down much easier (my subjective opinion). For example I would use C# for the UI, the back end, and use MSSQL for the database. Nothing at all wrong with non-Microsoft vendors, I'm no Microsoft fan-boy, I just struggle to get productive with unfamiliar tools. Depends where your experience lies though.
Database: In particular I've found that .NET and MSSQL go easily together. When I started the project I was using a PostgreSQL (because it's free, fully featured and has open-source warm fuzzies). However I abandoned it in favour of MSSQL simply because it was taking me too long to get database work done in an unfamiliar language with unfamiliar tools. Also, I'm not sure MSSQL is so expensive anymore, for example for a web application, MSSQL 2008 Web Edition is pretty damn cheap per-processor I think (only on SPLA licensing though). If you're concerned about database features in a free implementation though, personally I think PostgreSQL has a very full feature set, nicely standardised, and rapidly growing.
UI: I'm pretty inexperienced, but ASP.NET MVC looks far less painful to me than ASP.NET Web Forms. I like PHP too, but again I'd match the UI language with the back-end language, so would recommend .NET.
On frameworks, I'm immersed in DALs at the moment. I like Subsonic for lightweight data, NHibernate for heavy-weight.
I still have a long way to go with my project so perhaps I can only see the short-term benefits and drawbacks at the moment. But in general I would say: use the technologies that you're most comfortable using, as you'll be way more productive and the end result will probably be about the same anyway. If you want to learn new technologies though, and who doesn't? - go ahead, just expect it to take a lot longer.
Didn't want to answer 'cause it's so open ended. But a few points:
Money
First, check out BizSpark. That should take care of any money aspect for 3 years. For a service company, that means not only free VS Team Suite and Office and so on, but free Windows, SQL, etc. If your startup can't afford to spend a bit on MS tech in 3 years, it's probably a bad business. So that takes out licensing.
On a similar note, Sun has Startup Essentials. Could be interesting on the hardware side of things, but I haven't actually competitively priced them versus Dell/HP.
Software
It doesn't sound like you have hard enough requirements to say "oh, this slightly-less-popular software X is perfect for my domain Y and is gonna give me a very big boost". In fact, your project might not be like that at all. Maybe it, technically, is going to be a relatively plain application just pushing data around or whatever. You didn't specify.
For a small startup, personal productivity is probably going to trump any other argument. If your people are excellent in X, then that's one of your top arguments right there.
If you really don't have any particular system you're most comfortable with, be conservative. Stick with .NET or Java, as they'll give you the widest range of useful possibilities.
As far as things like OS and Database, I'm biased, but I think Microsoft will give you platforms that are easier to take advantage of than you'll find elsewhere. For instance, setting up load balancing, clustering, centralized authentication, managing servers (updates, events, etc.) is going to be easier to get going on Windows than it would be on another platform, assuming you're not an expert in either. Configuring SQL Server, even the advanced features, is a piece of cake. (Go time someone who knows neither: Setup a DB mirror in MSSQL and MySQL -- which is going to take more work?) Again, this is all predicated on you not having experts in a particular set of technology.
Don't mix -- whatever you do, stick with the platform. If you go .NET, MSSQL is going to work better with the data providers (or things like Linq-to-SQL). If you decide to do PHP, then use MySQL as everyone else uses it and you'll encounter less resistance. If you're not inventing stuff on the technical side, don't become an edge case.
You should pick the platform first, then the language that is best for that platform (if there is any choice).
One thing you should consider is the labor pool, and labor pool cost, for specific platforms and languages. Human Resources can often get cost metrics, if you don't have ideas already.
In my town, for example, .NET platform is much more expensive per Software Engineer than open source, because the .NET developers have a higher rate (40% roughly). C# is a little higher rate than VB.NET, but also tends to bring more well rounded candidates.
Just to throw in something totally different: How about weblocks as a web framework? It uses Hunchentoot as a server, which can run either standalone or with Apache. This is all done in Common Lisp. Weblocks can use cl-sql as a backend store, which can connect to many different RDBMs (MySQL, PostgreSQL, Oracle, ODBC, SQLite).