Main > Everything Else

Small Business, Why have a SQL database?

<< < (2/3) > >>

kahlid74:
As others have said SQL is a great tool but I would suggest you grasp it completely before investing your time and data to it.  Remember, you're the support for it, so if you move your data to SQL and then it breaks or doesn't work you're the front line of support.

So yes, I would say it's worth using and migrating too but only if you take the time upfront to learn it and implement it right as others have said.

sandheaver:

--- Quote from: kahlid74 on March 12, 2013, 09:11:41 am ---As others have said SQL is a great tool but I would suggest you grasp it completely before investing your time and data to it.  Remember, you're the support for it, so if you move your data to SQL and then it breaks or doesn't work you're the front line of support.

So yes, I would say it's worth using and migrating too but only if you take the time upfront to learn it and implement it right as others have said.

--- End quote ---

Agree 100% with this.

ark_ader:

--- Quote from: sandheaver on March 12, 2013, 10:22:46 am ---
--- Quote from: kahlid74 on March 12, 2013, 09:11:41 am ---As others have said SQL is a great tool but I would suggest you grasp it completely before investing your time and data to it.  Remember, you're the support for it, so if you move your data to SQL and then it breaks or doesn't work you're the front line of support.

So yes, I would say it's worth using and migrating too but only if you take the time upfront to learn it and implement it right as others have said.

--- End quote ---

Agree 100% with this.

--- End quote ---

+10

SQL is piss easy.    ::)

sdweim85:

--- Quote from: shponglefan on March 11, 2013, 06:35:09 pm ---Being intimately familiar with both SQL databases and Excel, here are my 2 cents:

First, it depends on the data.  If you're just listing Backup Drive #X and Project #Y, then Excel is probably sufficient depending on how many projects/drives were are talking (dozens, hundreds, thousands?).  If you are storing more data than that, then a database can be more ideal.  Especially if you need to run searches on specific criteria.  But judging from the OP, that doesn't sound like the case.

Another thing to consider is migration: Excel is pretty ubiquitous.  Most people know how to use it and it's relatively easy to learn, so if you quit and someone else takes over then it's probably not an issue for them to use/adopt the same spreadsheets you were using.  SQL and general database management is more specialized; not a lot of people know how to create/use them, so if you ever leave your job, then it could be more problematic for the next guy.

Also, the "do it right the first time" mantra is a good idea in theory.  But this assumes you really do "do it right".  I've seen cases where databases have been set up incorrectly from the get go, and as a result can be a PITA to fix later.  If you don't have a background in database management/SQL, then trying to set it up from scratch will be a learning curve and chances are you'll make mistakes.  So I wouldn't necessarily recommend doing that until you know what you are doing.

--- End quote ---

The data I'm inputting is very simple.  We just have 20 backup drives, and I have an excel sheet of all the projects on them.  I COULD add many variables for each project like, job description, size, output, input, time completed.  All that stuff, but its really irrelevant.  We already know how long things will take to complete since we break it down by image*time=completed job.  Also put in the DB things like Serial keys for programs, username and passwords. PCs with their specs.

Also the backup drives of previous projects is only just in the customer we did the project for loses their backup.  We keep it in good faith for them, they don't actually pay for us to backup their work and keep it forever.  Eventually after a year or two we delete it.

sandheaver:
PC hardware & software inventories; you can collect that stuff dynamically when needed.  I don't see a reason to store that at all, except maybe to detect changes.  Small shops don't care a lot about that.

Usernames & passwords; if you're storing user's usernames & passwords, then you're Doing It Wrong(tm).  You didn't specify, and I assume the worst. 

Project backups wouldn't go in SQL, though metadata might.  you can usually encode the needed stuff in the filename, or just put a .txt file in the backup with those details.  Not SQL.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version