Background
My research group and I are developing a database to store our data and we are building an software tool that simplifies access to these data. The database will holds data that has been published and that we would like to make available, alongside data that has not been published and that belongs to other researchers.
Objective
We would like for our work to be easily reproducible, and to this extent, we need to allow the public to run SELECT statements on the data. Three possible solutions include:
for each publication, create a subset of the database that can be freely downloaded (possibly in a virtual machine so that the dependencies of the software tool are met)
for each publication, create a many-to-many lookup table that links data records to publications, and then provide public SELECT permissions to access these records. We could easily replicate the database for public use
Parameterization modules
Automation of prior generation
However, I have been told that even allowing wildcard statements compromises security, which is why I consider option 1 more plausible. Option 1 would also enable us to archive the database as it was used with a particular publication.
update: to clarify, I want the users to be able to reproduce the entire computational workflow, which requires using SELECT statements that can join data tables with auxillary data (like covariates, experimental details) in lookup tables.
Question
What is the best way to provide public access to a subset of the database?
You can distribute subsets of data as a SQLite database, that is, create a standalone datafile that people can download to their own computers. Many scholars, economists, etc use SQLite to share datasets because it is self-contained and installation is painless (and I should add, cross-platform).
Create views with appropriate access privileges, and users that can only access these views, but no underlying tables.
Related
I am looking for a solution that lets me interconnect several databases.
But let me explain it with the exact example:
I have a main domain (front page for public clients) and four sub-domains (development, management, client, ...) in the clients webhosting.
Each domain has its own database and runs different software (WordPress, dolibarr, sysPass, our own software), but all databases are stored on the same mySQL server.
If a CRUD is made, I want that the other databases also "do" something with that data.
Basically, automation.
For example - a user on development.subdomain.xyz sets a project task to "finished".
When the UPDATE is done to the "development" database, I want an INSERT with parts of that data into the "management" database and an UPDATE towards the "client" database.
I could write up some script that connects to all four databases and does the operations necessary.
But that feels a little hard to maintain if multiple users shall have access to this "logic" system?
I could also use the provided API's and process the data (again in a script form rather than implementing a whole UI).
That feels like adding an unnecessary, extra security concern and again hard to maintain?
If I want to add additional functionality - like sending an Email as well, that would even make it harder for non-coders to interact.
So I found several of these "Low-Code Business Process Management" tools and now I'm at a loss.
Is that what I'm looking for? Can you throw me some tags, keywords or links to guide my search for possible solutions?
I do not even know how to call such a system or search for it - which stops me from progressing.
Thank you for all tips :)
So I'm moving from MS Access to MySQL:
In MS Access you can store certain INSERT, DELETE, and UPDATE queries as objects alongside your tables. Thus for anyone who don't understand computers that well, they can click on the objects and automatically run the queries to alter the master table for various business functions.
In MySQL, where and how do you store these queries, I seem to be only able to make tables. When I write a piece of code using the SQL editor, I can only save it to a remote location (such as my local desktop) and not onto the MySQL database, where it's accessible for my coworkers.
If you can't save it onto the server, how would I write a piece of code and execute it within the database that would be easily usable by others.
Thanks
The answer to this question is going to depend on your environment, your users, and your bandwidth to support any given solution. You are gaining a lot by making the switch from Access to MySQL, however you are losing some of the the WYSIWYG features. (e.g., Access forms that can bind directly to your data source.)
There are many approaches:
If your users are more advanced, simply having access to the database using MySQL Workbench may suffice. From there they would have access to run views, stored procedures, or to create their own custom queries.
Another option would be to script your objects using Python and provide a simple gui using TkInter. Python is generally thought of as an easy to use language; with built in suppport for MySQL and TkInter is its "default" interface.
Using the LAMP architecture is another largely popular paradigm using MySQL as the backend database.
There is also nothing stopping you from using Access to link to your MySQL db using MySQL as an external data source.
I hope this provides enough info to help you begin whittling down your options.
We got an application wherein multi-tenancy is implemented by having a unique database (MYSQL) for each tenant. The table structures are the same. I got a requirement to list all expiring products for each of the tenants, and I was wondering how can I incorporate all those in one data web service in WSO2? I know that I can create a query with the database prefixing the table:
eg. select DB1.products.id, DB1.products.name from DB1.products
Do I need to define a data source for each database (100+ tenants), and can I specify the database name as an input variable in the data service operation? ie. select ?.products.id, ?.products.name from ?.products
Thank you for your help.
Cheers,
Erwin
If your intention is to have a generic data service that would retrieve those tenant specific information from those database dedicated to each tenant, as I see, the most cleanest way to achieve this would be by generifying your SQL queries and making the used datasource dynamically discoverable.
Since you're using 100+ tenants(WOW that's a huge number :)) obviously you might be having 100+ databases created for those tenants too. So, you would need to create a carbon datasource with the same name in each tenant (let's say "testDS") wrapping the tenant specific database configurations such as JDBC URL, credentials, etc. Next, if you've come up with your dataservice configuring the used datasource to be the aforementioned datasource, at runtime, it would correctly pick up the appropriate tenant specific datasource as the datasource feature completely supports multi tenancy. That would prevent you from passing the database name, etc to the SQL query and make your data service configuration more clean, generic thereby making it more maintainable.
is it possible to create a graphical representation of specific object in database Schema and all it relationships with all linked metadata, views, and stored procedures assocated with this object? Example: I want to define a logical relationships between “Data Sheet” tab on Prestashop product page and the rest elements in a database schema.
Yes (partially) - use the mysql workbench. It has reverse engineering db tools
see mysql dev wb link
This will generate diagram of the tables + relationships. Stored procedures, views, trigger etc are not going to be supported (too complex). You will just have to browse and reverse them yourself.
Yes, you can find PrestaShop's new Physical Data Model here: http://www.prestashop.com/blog/en/a-new-physical-data-model-available-for-prestashop/
There is a MySQL workbench model in the dev directory of the Prestashop distribution (although the last one I looked out was out of sync with the actual release database schema, although that could have been a development release). I would make that my first point of call. Unfortunately it won't show up every relationship between tables though.
One of the quickest ways to do analysis is to take a snapshot of the database, insert a particular record (user, order, customer, data sheet etc.), take another snapshot, then diff them.
I'm trying to split a database into two pieces -- a backend that updates automatically, and a front-end that allows searching and adding/editing comments. The data in the source database is pulled together from multiple tables into a pair of queries, and I want to use these queries as the source of the current database.
Access 2007 supports splitting a database into multiple pieces, but not in the way I'm looking for. It keeps the tables in the source database and puts all the forms, queries, reports, and macros into the new database. The tables and queries are already in the back-end, and this new database should just provide a good GUI to the end-user.
Access 2007 also supports linked tables, but these can only use a table as a source, not a query object.
I was thinking that the best way to do this would be to do a SQL query along the lines of
SELECT * FROM SourceQuery IN "C:\Path\To\ExternalDB.accdb";
Is what I'm working towards even possible, and would this be the best way to do it?
Since its still relatively early in the project, rearchitecting the database isn't out of the question, but is something I'd prefer to avoid.
You described the usual Access BE-FE division correctly: only tables in the back-end. I'm aware not all DB programs do it that way, but this is Access and my approach would be to honor the usual division. (And you hardly have a choice in that you can't "link to a query" in Access.)
Reviewing your comment ('There is a specific reason ...'), I think this would possibly mean
adding a few more tables to the back-end, essentially buckets (import-data in ready form; export 1; export 2) that allow all users to get to consistent processed data;
making a small admin FE that sits next to the BE and stores your modules, queries for export, and export routines; and
having some redundant queries on the user FE. This is vexing in my own work. I just try to design sturdy stable "building block" queries in those roles, and keep their number to a minimum.
Hope I'm understanding you correctly, but the most sensible solution would be to link the tables in the backend DB and copy the queries to the UI database. Those queries would still be able to access the uderlying tables (via the linked tables) without issues and would be accessible through normal means to your forms and VBA code.
Is there a particular reason you don't want the queries in the UI database?