I'm pretty clueless about SQL and how to layout a database.
I want to store users and character sheets inside an SQLite database. I'm not really sure how I should structure my databases. I plan on the following thing:
A table of users with a reference to the characters.
A table of characters that contains all values that can easily be structured.
A table of skills that contain a reference to the character that has it.
Tables for everything that has multiple values per character in a similar fashion.
Since most of these things, that can have multiple values are simple strings I would prefer having a column that has an array.
I'm using sqlite3.
Do you think an array column is a good idea and even possible?
Related
i wanted to create via Excel or Oracle a database for a Storage room that is filled with all kinds of Computer parts and stuff.
I never created something like that, so i wanted to know if you could help me out giving me an advice how to create a database for a beginner
It should be possible to insert and remove parts or even update them
Hope my question is readable and understandable.
Thanks
A simple option to do that - not only the table so that you could write your own DML statements (to insert, update or delete rows) - but to create a nice application - is to use Oracle Application Express (Apex).
Depending on database version you use, it might already be installed by default. If not, ask your DBA to install it.
Alternatively, create a free account on apex.oracle.com; you'll get limited space (more than enough to do what you want to do).
In Application Builder, use the Excel file you have as a "source" which will then be used by Apex's wizard to create a table in the database, as well as application, true GUI which works and looks just fine.
If you don't have anything at all, not even an Excel file, well ... that's another problem and requires some more work to be done.
you have to know what you want (OK, a storage room)
is a single table enough to contain all information you'd want to collect?
if so, which columns (attributes) do you want to collect?
if not (for example, you'd want to "group" items), you'd need at least two tables which will be related to each other by the means of master-detail relationship, which also means that you'll have to create a foreign key constraint
which datatypes are appropriate for certain attributes? You wouldn't store item names into number datatype, right? Nor should you put dates (when item entered the storage room) as a string in varchar2 column, but into a date datatype column
etc.
Basically, YMMV.
I am trying to create a database with field descriptions for a very large excel file that I have at work. I have created 3 tables- List of sheets, list of variables(including a lookup field pointing at the List of sheets table, so that I can select the sheet to which the variable belongs), and a third table which specify some validation rule.
In this third table, I want to see two lookup fields, one specifying the sheet in which the rule applies(say, 'Select Sheet'), and another specifying the variable(say, 'Select Variable'). I can point to the two different tables, but I want to do something a bit more nuanced than that. When I give a particular sheet name to 'Select Sheet', I want the lookup field for the variable('Select Variable') to show me only those variables which exists in that sheet.
I know that there probably will be solutions using forms, but this database is going to be very detailed and there are things to do afterwards, so I do not want to get into queries and forms before all data has been recorded in tables in a neat manner.
I have a good grasp of VBA in the context of excel and I am given to understand that I can extend the applications of Access using VBA. I am ready to do that, but I want to see before that whether this is some functionality of access that I am missing. Had anyone done anything similar before, and if so, did it take VBA to do it?
My project currently has a database which contains several tables, the most important of which has one binary column with very large entries (representing serialized C# objects). There are a large number of entries in the production database, and when debugging, it is often necessary to pull these entries down into the local development database (as remote debugging does not seem to work, which is a separate issue).
If I attempt to compare the local and production databases on this table with all columns, the comparison can take up to an hour, or eventually time out, but this has worked in the past and allowed me to download the entries and debug them successfully. If I compare on all table columns but the binary data column, the comparison is almost instantaneous, but that column is not then transferred to the production database.
My question is: is there any way to run a data comparison between two tables, excluding a particular column for the comparison itself (other fields give enough information to differentiate without it) but including it when updating the target database?
You could use a hash function on your large varbinary fields and compare those. HASHBYTES with MD5 is a good method for comparing as it's astronomically unlikely to generate the same hash value for two different inputs. Problem is, HASHBYTES only works on fields up to 8000 bytes. There are some work arounds though by creating a function. A few posted here:
SQL Server 2008 and HashBytes
You would have the option of storing the hash values in your table at the time of insert or update by using a persisted calculated fields. Or you could just generate the hash values while doing your comparison query.
I'm working on a data conversion utility which can push data from one master database out to a number of different databases. The utility its self will have no knowledge of how data is kept in the destination (table structure), but I would like to provide writing a SQL statement to return data from the destination using a complex SQL query with multiple join statements. As long as the data is in a standardized format that the utility can recognize (field names) in an ADO query.
What I would like to do is then modify the live data in this ADO Query. However, since there are multiple join statements, I'm not sure if it's possible to do this. I know at least with BDE (I've never used BDE), it was very strict and you had to return all fields (*) and such. ADO I know is more flexible, but I don't know quite how flexible in this case.
Is it supposed to be possible to modify data in a TADOQuery in this manner, when the results include fields from different tables? And even if so, suppose I want to append a new record to the end (TADOQuery.Append). Would it append to two different tables?
The actual primary table I'm selecting from has a complimentary table which is joined by the same primary key field, one is a "Small" table (brief info) and the other is a "Detail" table (more info for each record in Small table). So, a typical statement would include something like this:
select ts.record_uid, ts.SomeField, td.SomeOtherField from table_small ts
join table_detail td on td.record_uid = ts.record_uid
There are also a number of other joins to records in other tables, but I'm not worried about appending to those ones. I'm only worried about appending to the "Small" and "Detail" tables - at the same time.
Is such a thing possible in an ADO Query? I'm willing to tweak and modify the SQL statement in any way necessary to make this possible. I have a bad feeling though that it's not possible.
Compatibility:
SQL Server 2000 through 2008 R2
Delphi XE2
Editing these Fields which have no influence on the joins is usually no problem.
Appending is ... you can limit the Append to one of the Tables by
procedure TForm.ADSBeforePost(DataSet: TDataSet);
begin
inherited;
TCustomADODataSet(DataSet).Properties['Unique Table'].Value := 'table_small';
end;
but without an Requery you won't get much further.
The better way will be setting Values by Procedure e.g. in BeforePost, Requery and Abort.
If your View would be persistent you would be able to use INSTEAD OF Triggers
Jerry,
I encountered the same problem on FireBird, and from experience I can tell you that it can be made(up to a small complexity) by using CachedUpdates . A very good resource is this one - http://podgoretsky.com/ftp/Docs/Delphi/D5/dg/11_cache.html. This article has the answers to all your questions.
I have abandoned the original idea of live ADO query updates, as it has become more complex than I can wrap my head around. The scope of the data push project has changed, and therefore this is no longer an issue for me, however still an interesting subject to know.
The new structure of the application consists of attaching multiple "Field Links" on various fields from the original set of data. Each of these links references the original field name and a SQL Statement which is to be executed when that field is being imported. Multiple field links can be on one single field, therefore can execute multiple statements, placing the value in various tables, etc. The end goal was an app which I can easily and repeatedly export a common dataset from an original source to any outside source with different data structures, without having to recompile the app.
However the concept of cached updates was not appealing to me, simply for the fact pointed out in the link in RBA's answer that data can be changed in the database in the mean-time. So I will instead integrate my own method of customizable data pushes.
It's possible to store data clusters inside the database using import and export statements, together with a dictionary table which adheres to a template (at least has the fields MANDT, RELID, SRTFD, SRTF2, CLUSTR, CLUSTD).
Here's two example statements which store/retrieve an entire internal table ta_test as a data cluster with name testtab and id TEST in the database, using dictionary table ztest, and area AA
export testtab = ta_test to database ztest(AA) id 'TEST'.
import testtab = ta_test from database ztest(AA) id 'TEST'.
Looking at the contents of the ztest table, I see the following records (first 4 fields are the primary key):
MANDT 200
RELID AA
SRTFD TEST
SRTF2 0 (auto-incremented for each record)
CLUSTR integer value with a maximum of 2.886
CLUSTD a 128 character hexadecimal string
I've also noticed that the amount of data stored this way is a lot less than the data which was inside the internal table (for instance, 1.000.000 unique records in the internal table result in only 1.703 records inside the ztest table). Setting compression off on the export statement does increase the amount of records, but it's still a lot less.
My questions: does anyone know how this works exactly? Is the actual data stored elsewhere and does ztest contain pointers to it? Compression? Encryption? Is the actual data accessible directly from the database (skipping the ABAP layer)?
The internal format of data clusters is not documented (at least not in an official documentation). From my experience, it does contain the entire data and not just pointers: Transporting the table entries to a different system -- as you do frequently when transporting ALV list layouts -- is sufficient to move the contents over. Moreover, the binary blob does not seem to contain much information about the data structure - if you change the source/target structure in an incompatible way, you risk losing data. Direct access from the database layer is not possible (this is actually stated in numerous places all over the documentation). It might be possible to reverse-engineer the marshalling/unmarshalling algorithm, but why bother when you've got the language statement to access the contents at hand?