February 21, 2013 at 7:09 am
For the kind of website that was described, SQL server is not going to be appropriate, because none of the CMS's that are appropriate will use it as a back-end.
Or were we supposed to think that anyone would write a CMS from scratch in this day and age?
As for XML - is that meant to be a hierarchy of files, or a single monolithic schema? The latter is certainly not clever even if it is small enough to be held in memory.
February 21, 2013 at 2:43 pm
mike brockington (2/21/2013)
For the kind of website that was described, SQL server is not going to be appropriate, because none of the CMS's that are appropriate will use it as a back-end.Or were we supposed to think that anyone would write a CMS from scratch in this day and age?
As for XML - is that meant to be a hierarchy of files, or a single monolithic schema? The latter is certainly not clever even if it is small enough to be held in memory.
I agree with that, so I'm going to stick with my original reaction: I'll use a mixture of both plus a few other things besides. The answer given as "correct" (either will do) is utter drivel (I suspect it wasn't intended as anything else, some questions are there just to provoke debate and this could well be one of them) but "neither of them will do" isn't useful either ("neiother will do on its own" would be somewhat useful, of course).
Tom
February 22, 2013 at 1:59 am
great debat 45% only aggree with response
I use XML in columns with a project where database columns are moveable from year to year. It's a pratical solution but when a lot of updates are necessary it's tedious and slow
If I had to restart the project I will do the same thing but tools in SQL are not really up to do such things
February 22, 2013 at 2:02 am
For mike brockington :
I did it 12 years ago and this CMS is again alive yet (in my enterprise) and I use XML and SQL
and all is working efficiently so ... why not ?
February 22, 2013 at 3:26 am
The question didn't say anything about being retrospective!
I won't question your decision to build your own CMS back then, but if you chose to do so today, then I would fire you without a second thought, hence compatibility is an important factor.
February 22, 2013 at 8:17 am
mike brockington (2/22/2013)
@jfgoudeThe question didn't say anything about being retrospective!
I won't question your decision to build your own CMS back then, but if you chose to do so today, then I would fire you without a second thought, hence compatibility is an important factor.
I find that somewhat amusing. Are any of the CMSs you can obtain instead of doing your own decent value for money? Will the long term cost of ownership be acceptable if you do it yourself? Will it if you buy instead? It will of course depend very much on your requirements, on whether you can buy something that meets them, on suppliers' prices, and perhaps on what the charge for customisation of a CMS that almost fits would be. And of course the requirements may include flexibility and enhanceability which mill be an issue with some bought systems and also with building your own if you don't have the right sort of development arm. You may even to look at commissioning a software house to create a new CMS for you.
Often build or buy decisions require careful thought, not a prejudged "always buy if there's anything for sale" or "always build because we'll make a better job of it", either of which could be a fatally flawed decision. I would value someone biased towards one answer much the same as someone biased to wards the other - both fail the simple test of being able to answer the question in front of them based on the requirements, the facts, the evidence rather than on their prejudices, so I wouldn't want to allow them to occupy a position where they could influence such a decision.
Tom
February 22, 2013 at 9:39 am
mike brockington (2/22/2013)
@jfgoudeThe question didn't say anything about being retrospective!
I won't question your decision to build your own CMS back then, but if you chose to do so today, then I would fire you without a second thought, hence compatibility is an important factor.
WOW. Somewhat infexible and closed minded, ya think!
February 22, 2013 at 9:44 am
I guess some people have difficulty in recognising a little humour when its thrown down!
In reality I would have followed all proper procedures, and given our friend a chance to explain his decision to waste hundreds of man-hours re-inventing a wobbly wheel, but I would definitely still fire him at the end of the process... :kiss:
February 22, 2013 at 10:35 am
mike brockington (2/22/2013)
I guess some people have difficulty in recognising a little humour when its thrown down!In reality I would have followed all proper procedures, and given our friend a chance to explain his decision to waste hundreds of man-hours re-inventing a wobbly wheel, but I would definitely still fire him at the end of the process... :kiss:
I think your termination decision may be based on a couple of false assumptions that I've seen in several companies that consider 'Commercial off-the-shelf' (COTS) solutions due to perceived savings.
The first is that a COTS solution is inherently better. Most vendor solutions are structured very generically, so that they can be custom tailored to a wider audience of customers. They also often contain much broader functionality than required. Both of these factors add to the complexity of implementation. Often overlooked are other existing systems that will require interfaces with your COTS solution. Replacing other systems or creating custom interfaces can add more development time than estimates for implementing a properly scaled in-house solution. The effort required in tailoring COTS software to meet specific business needs is often overlooked in determining savings of effort.
Another is that COTS solutions are inherently cheaper. There's an assumption that you will save development time (which isn't always the case, see above), but you have licensing and support costs and support is limited to what the vendor is willing to provide. Future customization requirements that don't fit with the vendor's development path can be quite expensive and less than timely.
February 22, 2013 at 11:17 am
sestell1 (2/22/2013)
mike brockington (2/22/2013)
I guess some people have difficulty in recognising a little humour when its thrown down!In reality I would have followed all proper procedures, and given our friend a chance to explain his decision to waste hundreds of man-hours re-inventing a wobbly wheel, but I would definitely still fire him at the end of the process... :kiss:
I think your termination decision may be based on a couple of false assumptions that I've seen in several companies that consider 'Commercial off-the-shelf' (COTS) solutions due to perceived savings.
The first is that a COTS solution is inherently better. Most vendor solutions are structured very generically, so that they can be custom tailored to a wider audience of customers. They also often contain much broader functionality than required. Both of these factors add to the complexity of implementation. Often overlooked are other existing systems that will require interfaces with your COTS solution. Replacing other systems or creating custom interfaces can add more development time than estimates for implementing a properly scaled in-house solution. The effort required in tailoring COTS software to meet specific business needs is often overlooked in determining savings of effort.
Another is that COTS solutions are inherently cheaper. There's an assumption that you will save development time (which isn't always the case, see above), but you have licensing and support costs and support is limited to what the vendor is willing to provide. Future customization requirements that don't fit with the vendor's development path can be quite expensive and less than timely.
Another important issue is product lifetime. COTS solutions often turn out to be a false economy because a couple of years down the track the supplier decides to stop selling that product and end support. They often turn out to cause enormous problems because they are not properly maintained at all, even when the customer is paying through the nose for support.
Tom
February 26, 2013 at 5:35 am
I think you are both missing the point, which is that the original question was seriously lacking in detail, and fell way below the level of professionalism that most of us expect from this site.
February 26, 2013 at 6:01 am
mike brockington (2/26/2013)
I think you are both missing the point, which is that the original question was seriously lacking in detail, and fell way below the level of professionalism that most of us expect from this site.
Well, I think you have missed the point allowing yourself to believe that you can determine the right choice between build and buy discussion when you have nothing but a pretty vague and imprecise requirement statement to go on falls way below the level of professionalism that should be expected, and displays an unfortunate tendency to bias/prejudice.
I disagree with you abpout the question too: as I said three weeks ago,
It's a good question in that it provokes debate: but it's a terrible question in that all four options provided for the answer are unmitigated balderdash. The former is, of course, far more important than the latter.
Tom
February 26, 2013 at 7:03 am
Well, I have said it already, but for the last time - my first post was a little bit ironic, and not intended to be taken seriously. On the other hand, the original question had only one "correct" answer, so it may have provoked debate, but was not appropriate as part of a sequence where scores were given.
On the other hand, I am amazed that you would enter a debate about CMS systems, without being aware of how many FOSS projects there are, in every possible flavour, in addition to "quite a few" COTS systems...
Viewing 13 posts - 61 through 72 (of 72 total)
You must be logged in to reply to this topic. Login to reply