a modders' database - feeler

[alyctes]

I'm learning Python and SQL, in an effort to make myself more marketable, ho ho.

This comment [url="http://basschat.co.uk/topic/227421-thomann-selling-harley-benton-basses-as-decoration-only/page__view__findpost__p__2851898"]http://basschat.co.u...ost__p__2851898[/url] made me wonder if it would be worthwhile setting up an online searchable database for people who want to know things like the neck pocket dimensions of Hohner B Bass B basses, nut widths, truss rod adjuster sizes, that sort of thing.

Would anyone apart from me find this useful?

Edited August 26, 2015 by alyctes

[Machines]

Would that have enough data? It could probably be achieved in Excel. Multiple tables aren't really needed.

[SeanNeedham]

Depends on what sort of search you'd be planning to use, because just to find dimensions of something simple tabular data would work.

If you were taking it more in depth like X body has a neck pocket of Y and A, B, C necks would fit in to that, then it'd probably be more worthwhile to create a database and application over the top.

A bit of advice on this before you start looking at your data storage, and even the language used to retrieve/insert that data, make a pot of brew and sit down with a notepad and pen and decide clearly what you want the end point to be and how much you are wanting it to do. Once you have that down it'd make it a lot easier a decision to what you need to do to get there and a lot less work in the construction phase.

[pfretrock]

[quote name='Machines' timestamp='1440565276' post='2851920']
Would that have enough data? It could probably be achieved in Excel. Multiple tables aren't really needed.
[/quote]
I suspect enough data could be collected to make it useful. Excel is a pain in the arse, if you don't have it or don't like it. Online would be more useful. Because multiple tables are available, they don't have to be used. (besides, the best way to learn a new skill is to develop something workable having a defined objective. I did a project with php, which was a new skill for me. I would have liked to have used Python for this but the server did not run it too well).
I think the idea of nut width as an example is useful. Often it is not given and even a few mm makes a difference to me. (Scale length on the other hand makes little difference - I can easily swap between 30-32-34" and play all equally badly)
Not so sure about pocket dimensions as I think you'd need a drawing to check if you replacement neck would fit.
Then there is the pickguard minefield..... and bass weight, which would be useful

[3below]

[quote name='Machines' timestamp='1440565276' post='2851920']
Would that have enough data? It could probably be achieved in Excel. Multiple tables aren't really needed.
[/quote]

Depends on how much data will be kept, 3NF will make handling multiple instances easier e.g. variants on models such as Fender Precision / Jazz and further extension will be simpler. Python and SQL will make further use e.g. web much easier and give the OP the skills development wanted.

SeanNeedham gives good advice - thinking about possible end points and planning structures on paper saves much grief later on

[synthaside]

There's no reason why this couldn't be done easily enough with a couple of MYSQL tables and a tiny bit of PHP or python to do the lifting into your webpage , sounds like a nice little project for you to get learning in , M/y advice to you is to get the database populated as some tables first.

I would start planning out the database , Its been long old time since I've done this and this can be tricky for someone who isn't used to dealing with normal form , which the database will need to be in to deal with your search's to work properly .

Here's a quick starting point for your data design * lunch break* i'm sure someone far better with UML than I will come around to say that's utter bollocks but that should allow you to search for matches between bodies and necks .

[url="http://smg.photobucket.com/user/synthaside/media/bassdb_zpszmbgp0h7.jpg.html"][/url]

Edited August 26, 2015 by synthaside

[Paul S]

Great idea.



Hohner B bass has a set neck...

[alyctes]

[quote name='Paul S' timestamp='1440743590' post='2853386']
Great idea.



Hohner B bass has a set neck...
[/quote]

Thanks

My B Bass B doesn't... possibly I am not aware of the Hohner range.

[Norris]

You might find this challenging due to the sheer number of variants even within a given bass range e.g. Precision. The neck pocket would be the hardest to define - depth, length, width, corner radius, end of neck radius, etc. Then you have the pick guard issue, fit of pickups, third party parts...

Having said that, it would be a very handy resource. You would need to allow users to enter data and edit it though, as it would be nigh on impossible to maintain it all yourself (site membership).

I'd probably start off with tables for brand, model, body, neck, pickup; and then relate them. Some may be a many-to-many join, so do another table for the relationship; on other tables a simple foreign key would suffice.

[SeanNeedham]

I've been thinking on with this, and in relation to what Norris said (and also scratching a bit around on some paper to get an idea of the architecture of the beast) it may be a bit of an uphill struggle for a "learner" project (not including data for populating the tables!), and with being an online resource Python may not be the best choice.

As it is, in simplistic terms what I've pulled up would be the db itself, a secure administration area (as you'd only want trusted members to modify database entries, and it'd be a pain in the danglers doing something like this through phpMyAdmin) but also maybe something where the end user can submit data on their instruments, then the search system itself (which I'd modularise to accommodate only specific relationships as it'd be a lot lighter on the code instead of trying to build a search everything model), as well as perhaps full information reference pages for each major component, then being able to package this up in a way that the end point user expects to work (in design of something like this, the old adage of "Make something idiot-proof and they will design a better idiot" comes to mind) and display on whatever device is being used to access the system.

I don't want to sound like I'm putting a dampener on it, but from personal experience it's not going to be an easy build and I wouldn't want to see you getting to the position of it having an adverse effect on what you are wanting to achieve in the long term with the languages you are looking at working with. I'd probably approach this idea as a "long term" project goal and build little projects to start with and from each of them when you've completed them look at what works, what experience you've gained on them and then in a year or so come back to this and it'd be clearer to see where them little nuggets would fit in to the overall aspect.

[Norris]

Btw, my day job is C# and SQL Server. Give me a shout if you want any advice