I am looking for a package that makes it easy to treat RDBMS in the same way you would treat data frames by automatically translating base R commands into valid SQL statements. I know that there is the dbplyr package but I am not a big fan of the tidyverse.
Is there a solution available that converts base R into SQL?
Related
I want to convert the data in one of my columns to another language ... is there any function in sql for translating it?
No, there are no SQL functions/procedures for translating between languages built into the Oracle database.
Oracle Text has features for multi-language indexes; but that is for indexing documents and not for translating them.
Oracle 12c and later also has features for translating between different SQL dialects; but that is not for translating data.
If you want to translate data then you will need 3rd party solution that you can import into the database or external software that you can call from the database.
After trying a few different packages and methods found online, I am yet to find a solution that works for inserting a dataframe from R into an existing table in SQL Server.
I've had great success doing this with MySQL, but SQL Server seems to be more difficult.
I have managed to write a new table using the DBI package, but I can't find a way to insert into using this method. Looking at the documentation, there doesn't seem to be a way of inserting.
As there are more than 1000 rows of data, using sqlQuery from the RODBC package also seems unfeasable.
Can anybody suggest a working method for inserting large amounts of data from a dataframe into an existing SQL table?
I've had similar needs using R and PostGreSQL using the r-postgres-specific drivers. I imagine similar issues may exist with SQLServer. The best solution I found was to write to a temporary table in the database using either dbWriteTable or one of the underlying functions to write from a stream to load very large tables (for Postgres, postgresqlCopyInDataframe, for example). The latter usually requires more work in terms of defining and aligning SQL data types and R class types to ensure writing, wheres dbWriteTable tends to be a bit easier. Once written to a temporary table, to then issue an SQL statement to insert into your table as you would within the database environment. Below is an example using high-level DBI library database calls:
dbExecute(conn,"start transaction;")
dbExecute(conn,"drop table if exists myTempTable")
dbWriteTable(conn,"myTempTable",df)
dbExecute(conn,"insert into myRealTable(a,b,c) select a,b,c from myTempTable")
dbExecute(conn,"drop table if exists myTempTable")
dbExecute(conn,"commit;")
I would like to use h2o model (either run in R or in flow) as an operational predictions. However, I would like to run it directly from Oracle sql. Is there currently a way that h2o translate .predict in sql code?
Thanks
This is hopefully a nudge in the right direction, but definitely not a complete answer.
Looking at this documentation:
https://docs.oracle.com/cd/B28359_01/appdev.111/b28370/create_function.htm#LNPLS01370
It looks like the CREATE FUNCTION capability allows the creation of Java functions.
You could perhaps take an H2O-generated POJO (Plain Old Java Object), wrap it in a Java function, and call it as part of a select statement.
Here is a pointer to a tutorial for how to do this for Hive:
http://docs.h2o.ai/h2o-tutorials/latest-stable/tutorials/hive_udf_template/index.html
That's not possible from within Oracle SQL - Oracle SQL databases can't execute R code natively. What you could do, is generate your predictions in R and then write them to a table in the Oracle SQL DB.
I have an application that is supposed to support two types of databases SQL SERVER and ORACLE. So we've been working forever on SQL Server and now we are making this support.
My idea was to create a tool to generate the scripts of creating the database using CMO then convert those scripts to PL/SQL Oracle scripts and run them on Oracle.
My questions are:
Is this syntax conversion possible in code?
I need a guideline to make this kind of syntax conversion.
Do you have a better suggestion to maintain two types of databases (i mean when making a change of one of them, we dont have to make it to the other. we need a tool to make that change.)?
If you write using standard sql it should be mostly portable. Eg use fetch instead of top, SET #a=.. instead of Select #a=.. Use Merge for updates instead of join updates, CURRENT_TIMESTAMP instead of getdate() etc.
I work in a project where the UI has direct access to the database through SQL code. The company has a framework where we create UI pages in xml and after that it is parsed and creates FLEX pages. If we want some data from the DB (Oracle) we add a sql query in the xml (instead of databinding with a datacontext object like we could do with WPF). If we want to add some logic, there is no code behind, we call store procedures. After we have the data we need the parser does the job.
The new requirements are to use the framework and create a new product that will be compatible with SQL Server and the thoughts are to start transforming the (Oracle)SQL queries to ANSI SQL.
Can somebody tell me the benefits and mainly the problems that we are going to face doing that?
Do you think there is a better way?
Note: The framework is really big and there are a lot of products built on that so managers are not keen to just throw it away(I tried but.. :))
Each dialect of SQL is different. You could use ANSI SQL but a) not all of ANSI SQL is implemented by most DBMS and b) most DBMS's have implementation-specific optimisations which will perform better for some cases.
So I'd say, don't go for ANSI SQL. It won't always work and sometimes it will work slower than taking advantage of a vendor's non-standard implementations.
Specifically, Oracle requires a StoredProcedure to return a REF_CURSOR from a stored procedure to fill a DataSet. SQL Server doesnt; the SP returns what the sp SELECTed. You're going to have to change your SP's to get rid of the returned REF_CURSOR.
Date handling is quite different: Oracle needs a to_date to turn a string into a date in where clauses etc; SQL Server just takes the string and converts it for you. And so on and so on. (I'm not at all sure what the ANSI Standard is, or even if it covers this!) To avoid changing your SQL you could add create SQL Server function called to_date, but this is now going to slow up your SQL.
If you have much PL/SQL in stored procedures, you have a big job converting it to T-SQL. They are quite different.
Good luck!