I created a database mdf file a while back and created a diagram of foreign keys. Lately, I needed to add several tables and there was an error saying I couldn't do the diagram because I'm not the owner.
So, I didn't update the diagram but added the tables anyway. My app seems to be working fine with the new tables. I'm using linq-to-sql and the design surface of the ORM doesn't show the connection between the new and the old tables.
My question is this: if the app works both with and without the diagram, what's the benefit of creating one? I know I can read an 800-page book and get the answer but I was wondering what the 2-3 line answer would be.
Thanks.
Diagram is just modeling tool.. no need to use it, but cool to visualise db, easier to write queries if you're not creator of db.
You can switch owner of db in options at "File" tab.
Related
This is a conceptual question, I am a developer who is familiar with Mongo & Postgres. In both of these DMS, you never have to create a table before using it. I don't really know how it works under the table but I create my Schema's in Mongo or my classes in Postgres (I use SQLAlchemy ORM) defining the structure of my different tables.
With DynamoDB I understand I can do the same but before adding an item/column into the table I need to check if the table is created? I don't really get how that works. Do I just create the tables the first time I create my db instance and if I add more tables I just create them once??
I understand the reasoning behind DynamoDB needing me to create the tables explicitly because they will allocate a certain amount of space in anticipation of the items that will be stored there but I have looked around and not really found a best practice or advice on when I should be creating new tables in DynamoDB?
Think of it this way: the DynamoDB table is the same as your Postgres database, not your Postgres tables. It's a piece of infrastructure that your service depends on, so you need to create the table at the same time you would create your Postgres database.
Also be sure to understand that unless you're doing some very, very complex thing, dynamoDb is intended to be used with 1 table per service. So if you're thinking "I need 4 tables", I'd suggest looking at this great aws video.
I used this blog post as a basis for creating my SQLite tables.
Using the SQL Server Compact/SQLite Toolbox, I can view the created tables nicely.
However, in order to first create the connection in that tool, I had to locate the SQLite database I had created. I did a hard drive search for it, and found it in:
C:\Users\Clay\AppData\Local\Packages\99129e92-ebeb-4800-a0e5-
d0e43b016009_qtyjefqf75sa6\LocalState\photrax.sqlite
Now how in the world would I know that it was in 99129e92-ebeb-4800-a0e5-
d0e43b016009_qtyjefqf75sa6 (there are many similar Welch-looking folder names beneath C:\Users\Clay\AppData\Local\Packages, so how would I know which one it's in)?
Surely there's a more elegant way to find it than doing a global search.
C:\Users\Clay\AppData\Local\Package is where all your apps store their data and 99129e92-ebeb-4800-a0e5-
d0e43b016009 is most likely your package ID from the appx manifest. You can just use ApplicationData.LocalFolder.Path to get the path.
I'm encountering a very odd problem. Since 2 days I cannot add new tables from my db in the model.
They appear in the list of addable tables, no error are shown at the validation but then, they don't appear in the Entity lists, and they still appear in the "addable" part of the menu.
The problem appears in
We've tried from different computeurs, so it's not a problem of my specific visual studio.
We've tried with other dbs, and the problem doesn't affect them. It affects boths of my prod and developpment dbs though.
We've tried with the exact same credentials to log to the db (not window authentication as we usually do), and the problem remains, so it's not a problem of rights.
We're a bit out of ideas right now :/
Does someone have an idea what it could be?
Thanks
Ok, we've found where it came from.
The table we wanted to add had no PK, and then when we tested we created mock tables without PK.
Once we add a PK the import goes well =)
If you're using a Code First approach then Entity Framework will build the table for you. It looks like you are not using Code First, so you will have create the table in the database. I assume you're using an Entity Data Model (.edmx)? If so, you will create your table in the database, then update your data model (.edmx). If you have not yet created your .edmx file, you need to do that - the .edmx file will contain all your CRUD operations.
What I'm confused about is I'd imagine your code would throw an error if the table did not exist (i.e. if the table represented by your data model didn't map to an actual table in the database, because it doesn't exist). So, the question is, does your table already exist? If it does, then step through the code line by line to find out why your records aren't being saved. If it doesn't exist, then add the table via SQL Server Management Studio (or similar), then open your .edmx file, right click on the layout that comes up, click "Update Model from database".
I have this issue with Core Data. I am creating a core-data-based application, for one of the tabs, to populate a UITableViewController. Basically, I have read somewhere that there is an issue with providing a pre-populated sqllite file to be used to load up the data. I created a pre-populated data file and at first had issues with Z_METADATA and other anomalies like that. If we are creating our own sqllite file, is there somethign we have to include, such as certain table names etc?
Note, I didnt create teh application with use core data for storage ticked at beginning, so im not sure if that makes a difference.
Doron, take a look and A Blog On Tech for a really great example of how to get what you are trying to do. Basically it's best to let Xcode create the base SQLite DB for you, copy it to your code directory, pre-populate your data there and then finally add it to the project through Xcode.
So while it is possible to work a Core Data application that you haven't created from the beginning in Xcode it is much easier to start from there.
I am playing with a CAD application using MFC. I was thinking it would be nice to save the document (model) as an SQLite database.
Advantages:
I avoid file format changes (SQLite takes care of that)
Free query engine
Undo stack is simplified (table name, column name, new value
and so on...)
Opinions?
This is a fine idea. Sqlite is very pleasant to work with!
But remember the old truism (I can't get an authoritative answer from Google about where it originally is from) that storing your data in a relational database is like parking your car by driving it into the garage, disassembling it, and putting each piece into a labeled cabinet.
Geometric data, consisting of points and lines and segments that refer to each other by name, is a good candidate for storing in database tables. But when you start having composite objects, with a heirarchy of subcomponents, it might require a lot less code just to use serialization and store/load the model with a single call.
So that would be a fine idea too.
But serialization in MFC is not nearly as much of a win as it is in, say, C#, so on balance I would go ahead and use SQL.
This is a great idea but before you start I have a few recommendations:
Be careful that each database is uniquely identifiable in some way besides file name such as having a table that describes the file within the database.
Take a look at some of the MFC based examples and wrappers already available before creating your own. The ones I have seen had borrowed on each to create a better result. Google: MFC SQLite Wrapper.
Using SQLite database is also useful for maintaining state. Think ahead about how you would manage keeping in mind what features are included and are missing in SQLite.
You can also think now about how you may extend your application to the web by making sure your database table structure is easily exportable to other SQL database systems- as well as easy enough to extend to a backup system.