[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 18/04/15 11:33, Mark Croft wrote:
The problem is that problems are problems. You cannot simplify things beyond a certain point and still solve the problem. People tend to write rubbish software when they don't understand the problem they are trying to solve. A spreadsheet may be easy to get started with but if you cant understand why a relational database is a good answer to the problem you probably dont understand the problem.i would not agree sql and databases are def not an easy thing to pick up and run with. Thats why most people use spreadsheets it seems an easy tool to program but get in a real mess when the problems get bigger then a few sheets and more complex logic etc. i agree sql and databases are the route too go but it will be a steep learning curve on this first project and depends how flexible the boss is. Do they have any idea about the reality of building computer programs etc , it magic to most people and there alway under estimate the time it takes to build a software system one of things that still plagues the computer industry the amount of projects that just get shelved and forgotten about. etc etc i could go go on about this subject pet hate and one reason i can't find a job anymore alongside disability and health problems also being out of programming job for 18 years and living off disability allowance and the roundabout of esa and jsa and icb(old esa) etc mark redditch worcesterhire. On 18 April 2015 at 08:50, Jay Bennie <jay@xxxxxxxxxxx> wrote:I'm sure this thread got to some conclusion, all i'll say is if your persistent with spreadsheets , then a pivot tables and vlookups are the way to do reporting and segmentation, and dropdowns. Tricky to master but worth it. ... However, it will be a pain in the arse and in the long terms unsupportable. (human error vs ability to constrain input = crap data = massive waste of time & errors) an option (and a good one for your use case : i strongly recommend a simple file based database for this use case This means no SQL server to make life complicated Can be put on a share drive Not vendor specific Options to develop further With an ODBC plugin use from excel. for more info see http://www.sqlite.org/about.html http://www.sqlite.org/download.html for an Access clone on Linux (i just found this OpenSource project - this is not a recommendation - it could be !) http://kexi-project.org/wiki/wikiview/index.php@xxxxxxxxxxxx re: SQL ... its super easy .... Select * from table where field = 'xyz'; but there are lots of tools to make ths pain go away .... Excel with an ODBC connection is an easy as specify a data source and a cell and press ok, the fields maps to the cols and you can add/edit as you like to the data. Solving the user input dilemma: When it comes to the user side ... you should invest a little energy in building an app or a web app. toolkits like cake php can give you validated CRUD web pages with looks ups and other bells a whistles with very minimal effort , investing 2-5 days learning and building something will be a worth while investment .... you will easily waste the same time with excel and get no where near the final outcome. at least with a app route your efforts will persist, and have a positive cumulative effect. and if your worries about infrastructure , just install xamp locally and do everything on your localhost until you get more proficient or want to spend a few # on an pc to make things more reliable ... or even host it cheap web host .. there is certainly no need to invest in expensive hardware. Best of Luck Jay -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq
Tom te tom te tom -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq