Xcode iOS phone directory app. core data, sql lite, or - sql

as part of an application I am trying to create, I am looking to data storage solutions. However, I have found many solutions that I can not quite directly apply to the position I am in.
Basically, I want to display in my app, a directory of the staff of my organization. About 100 or so individuals. I want to have generic attributes such as name, email, office#, etc.
However, my goal is to not end up with a static representation of the staff here! (people come and go, switch offices,etc.)
I am looking for the best way (if possible) to maintain a small database that I can administer, and if perhaps, something were to change to someone here, I can make the change and the change will be reflected accordingly.
Please help! I tried submitting my first app but got rejected because I relied on a webview to accomplish this task. This is an internship opportunity and my first real chance at development. Any help will be GREATLY appreciated.
Thanks!!!!!

The iPhone directory app can be used to store data in any format you want (xml, json or a proprietary format), because all you do is save a file. But if you choose to use the iPhone app directory to store data you have to write code to read the file (very simple to do) and parse the information (not so simple because the dificulty scales based on the information complexity).
SQLite is a tool to store structured data, providing you a set of tools to access and use the information. You don't need to parse the information, because SQLite does it for you by using transact sql queries.
By now, because you have a list of individuals, and these people are relationed to offices, I think you should use SQLite.
The Code Data is a object graph management, it's a tool to give you more options over data manipulation, and can make your life very easy if you have a lot of data and very complex data models. I don't think you need that for your particular problem, but I think you should learn it at some point.
UPDATE 1
You application will have something like:
A core database (sql server, oracle, my sql, etc) will hold your individuals information (your cloud database).
A web page (php, asp.net, etc) will display the core database information in json or xml format (your api).
A iphone app will download the information from the web page and store it in the local SQLite. (you have to decide when you will update the local sql lite, like when is opened, once a week, once a moth, twice a day, etc) (your local storage method).
Display the local SQLite individuals information in the app.

Related

Convert an online JSON set of files to a relational DB (SQL Server, MySQL, SQLITE)

I'm using a tool called Teamwork to manage my team's projects.
The have an online API that consists of JSON files that are accessible with authorisation
https://developer.teamwork.com/projects/introduction/welcome-to-the-teamwork-projects-api
I would like to be able to convert this online data to an sql db so i can create custom reports for my management.
I can't seem to find anything ready to do that.
I need a strategy to do this..
If you know how to program, this should be pretty straightforward.
In Python, for example, you could:
Come up with a SQL schema that maps to the JSON data objects you want to store. Create it in a database of your choice.
Use the Requests library to download the JSON resources, if you don't already have them on your system.
Convert each JSON resource to a python data structure using json.loads.
Connect to your database server using the appropriate Python library for your database. e.g., PyMySQL.
Iterate over the python data, inserting rows into the database as appropriate. This is essentially the JSON-to-Tables mapping from step 1 made procedural.
If you are not looking to do this in code, you should be able to use an open-source ETL tool to do this transformation. At LinkedIn a coworker of mine used to use Talend Data Integration for solid ETL work of a very similar nature (JSON to SQL). He was very fond of it and I respected his opinion, so I figured I should mention it, although I have zero experience of it myself.

How to create a SQL database within VB.net?

I am currently creating a vb.net program in which users upload a song file to the program and then it is saved within the programs files. I have set up the actual saving of the files but would also like to store some meta data of each in a SQL database within my program.
I have looked online and although i now understand the basics of SQL, im still a little fuzzy on how you actually implement this within VB.net. I have already added the library- Imports System.Data.SqlClient but failed to work out how to begin coding in SQL.
The basics of what im trying to acheive is a if statement that will determine wether or not a SQL database has been created in a specific location, and if it hasnt it should create it.
All constructive answers appreciated, thanks.
There are a number of different database engines available. The namespace that you have chosen contains the ADO.NET client classes for Microsoft SQL Server. You would use a connection string to specify how to connect to the database. This would often contain connection information, such as server name, user name, password etc, but it sounds like you want to store data locally.
There is a local version of SQL Server called LocalDB, but I think you would still need quite a lot of the SQL Server components installed for that to work. Although you can package these with your application they may be too large for you, so you may want to look at SQL Server Compact Edition, which is much smaller and allows you to package the whole engine as part of your application and is useful for storing data locally. Compact edition doesn't have quite all of the features that LocalDB does, so you may want to compare the features available for each.
Although you can use the ADO.NET objects to connect to a database, I think most people these days would use a layer on top which transfers data back and forwards between objects in memory and the database. This also allows you to use Linq to query the database in most cases. I personally use Entity Framework. You might want to look into that. There are different ways of configuring EF so you may want to look at a tutorial. Once you have it set up, you will probably find it much easier and safer to work with than writing SQL manually though.

How to create multi database support software?

I am creating a software for retail shops and I want that my software support SQL Server and SQLite. If the user is a standalone (one PC) select the sqlite database and if it is over the network then choose the SQL Server option.
I am developing this software in Visual Studio 2010 and vb.net language.
As research we have three types of connections in Visual Studio, ODBC, OleDB and MSSQL.
And OLEDB can support MS-Access database and SQL Server.
Any comment and idea is highly appreciated.
The best way to code your applications is to abstract functionality into different tiers or layers. This can mean lots of things and can get quite complex, but the general idea is to keep your application's parts separated. Let's assume you have an inventory form in your program where you can look up current inventory. The form that displays the inventory doesn't need to know what database your customer is running. Generally you're better served by it not knowing. Likewise, your code that accesses the respective database, whether it be SQL Server, SQLite, or Access, doesn't really need to know what your Inventory form is going to do with the data it is retrieving. All your Inventory code should be doing is displaying your inventory in a way that's most useful to your customer, and all your data coding should be doing is getting the data that is requested of it.
The route I would probably take in your situation is to create a data provider class. Inside that class is where you would encapsulate logic for the different database functions you may have, as well as the different database systems your customers may have. Say for instance a store owner just received a shipment of products and needs to add one to his store's inventory. Ideally, your program should simply be able to perform a call like DataProvider.AddInventory(). Inside the DataProvider class, you would write code to keep track of which database solution the customer is using as well as an implementation of logic for each of the database solutions you'd like to support. Ideally, you should implement every data function you may need your application to perform so that it can be called very simply like the AddInventory() example.
Implementations of data providers can be as simple or complex as you like. In some cases where you're going to have multiple applications written in multiple different languages on multiple different platforms accessing your data source from multiple locations, it may make sense to write some sort of middleware. In your case, it sounds like this is the type of application that will reside "in house" and should be served fine by abstracting the data access to a separate class.

What is the fastest way for me to take a query and turn it into a refreshable graph of the results set?

I often find myself writing one off queries to either answer someone's question or trouble shoot something and I would like to be able to quickly expose the on demand refreshable results of the query graphically so that I can share these results to others without having to go through the process of creating an SSRS report and publishing it to a reporting services server.
I have thought about using excel to do this or maybe running a local SSRS server but both of these options are still labor intensive and I cannot justify the time it would take to do these since no one has officially requested that I turn this data into a report.
The way I see it the business I work for has invested money in me creating these queries that often return potentially useful data that other people in the organization might want but since it isn't exposed in any way and I don't know that this data is something they want and they may not even realize they want this data, the potential value of the query is not realized. I want to increase the company's return on investment on all these one off queries that I and other developers write by exposing their results graphically so that they can be browsed by others and then potentially turned into more formalized SSRS reports if they provide enough value to justify the development of the report.
What is the fastest way for me to take a query and turn it into a refreshable graph of the results set?
Why dont you simply use what you may already have. Excel...you can import data via an ODBC / Oracle / SQL Connection. Get Data..and bam you can run the query and format it right in the spreadsheet and provide sorting etc. All you need to supply is the database name and user name and password to connect to the db.
JonH is right regarding Excel's built in ODBC support, but I have had tons of trouble with this. In my case, the ODBC connection required the client software to be installed so that it could use the encryption methods, etc. Also, even if that were not the case, the user (I believe) would still have to manually install and set up an ODBC connection.
Now if you just want something on your machine to do the queries and refresh them, JohH's solution is great and my caveats are probably irrelavent. But if you want other users to have access, you should consider having a middle-man app (basically a PHP script, assuming a web server is an option for you), that does a query, transforms the results into XML, and outputs it as "report-xyz.xml". You can then point anybody running a newer version of Excel to that address and they can very easily import the data into Excel with no overhead. (basically a kind of web service).
Keep in mind, I don't think you should have a web script that will allow users to make queries to your Database server! You would have some admin page where you make pass the query in and a new xml file with the results gets made. So my idea is also based on the idea that you want to run the same queries over and over without any specifics passed in. (if that were the case, I'd look into just finding a pre-built web services bridge for your database that already has security features built in. Then you could have users make the limited changes allowed.)

What are the Best Practices to follow while creating a data-dictionary?

I have large and complex SQL Server 2005 DB used by multiple applications. I want to create a data-dictionary for maintaining not only my DB objects but also cross-reference them against applications that use a specific object.
For example, if a stored procedure is used by 15 diffrent applications I want to record that additional data too.
What are the key elements to be kept in mind so that I get a efficient and scalable Data Dictionary?
So, I recently helped to build a data dictionary for a very large product. We were dealing with documenting more than one-thousand tables using a change request process. I can send you a scrubbed version of the spreadsheet we used if you want. Basically, we captured the following:
Column Name
Data Type
Length
Scale (for decimals)
Whether the column is custom for the application(s) or a default column
Which application(s)/component(s) the column is used in
Release the column was introduced in
Business definition
We also captured information about who requested the addition, their contact information, etc. Our primary focus was on business definition, and clearly identifying why a column was being used or created.
We didn't have stored procedures in our solution, but bear in mind that these would be pretty easy to add to the system.
We used Access for our front-end, even though SQL Server was on the back end. It made it pretty easy for us to build out a rich user interface without much work, using the schema we had already built out.
Hope this helps you get started--feel free to ask if you have additional questions.
I've always been a fan of using the 'extended properties' within SQL Server for storing this kind of meta data. In this way the description of each object lives alongside the object and is accessible by anyone with access to the database itself. I'm sure there are also tools out there that can read these extended properties and turn them into a nicely formatted document.
As far as being "scalable", I don't know of any issues related to adding large amounts of data as extended properties; or I should say I've never had any issues with this.
You can set these extended properties using SQL Server Management Studio 'property' dialog for each table/proc/function/etc and can also use the 'sp_addextendedproperty'.