rdbms

what should be considered before choosing hbase?

旧巷老猫 提交于 2019-11-30 16:21:39
I am very new in big data space. We got suggestion from team we should use hbase instead of RDBMS for high performance . We do not have any idea what should/must be considered before switching RDMS to hbase. Any ideas? One of my favourite book describes.. Coming to @Whitefret's last point : There is some thing called CAP theorm based on which decision can be taken. Consistency (all nodes see the same data at the same time) Availability (every request receives a response about whether it succeeded or failed) Partition tolerance (the system continues to operate despite arbitrary partitioning due

Oracle SQL to Sort Version Numbers

时光总嘲笑我的痴心妄想 提交于 2019-11-30 15:57:11
In Oracle, just using the ORDER BY does not sort version numbers. My Version_Number field is declared as a VARCHAR and I cannot change it. For Example: The following versions : 1.20 1.9 1.18 1.13 1.5 1.11 2.0 1.8 1.3 1.2 1.1 1.0 1.10 should be sorted as 2.0 1.20 1.18 1.13 1.11 1.10 1.9 1.8 1.5 1.3 1.2 1.1 1.0 I have researched several posts but none of them seem to really serve my purpose or the answers were intended for SQL Server, etc and not Oracle. I came across this particular sql which seemed to look like it worked. select version_number from mytable order by lpad(version_number, 4) desc

Calling an Oracle PL/SQL procedure with Custom Object return types from 0jdbc6 JDBCthin drivers

佐手、 提交于 2019-11-30 15:44:39
I'm writing some JDBC code which calls a Oracle 11g PL/SQL procdedure which has a Custom Object return type. Whenever I try an register my return types, I get either ORA-03115 or PLS-00306 as an error when the statement is executed depending on the type I set. An example is below: PLSQL Code: Procedure GetDataSummary (p_my_key IN KEYS.MY_KEY%TYPE, p_recordset OUT data_summary_tab, p_status OUT VARCHAR2); More PLSQL Code (Custom Object Details): CREATE OR REPLACE TYPE data_summary_obj AS OBJECT (data_key NUMBER, data_category VARCHAR2 (100), sensitive_flag VARCHAR2 (1), date_created DATE, date

Two foreign keys referencing the same primary key

£可爱£侵袭症+ 提交于 2019-11-30 11:54:09
问题 Is this okay to have two foreign keys in one table referencing one primary key of other table? EmployeeID is a primary key in the employee table and appearing as a foreign key twice in the timesheet table. There will be few admin users filling up timsheets on the behalf of other employees. In the timsheet table field 'TimsheetFor' will have employeeID of that person who has worked on projects and field 'EnteredBy' or 'FilledBy' will have employeeid of that person who has filled up this

Standard use of 'Z' instead of NULL to represent missing data?

試著忘記壹切 提交于 2019-11-30 10:21:23
问题 Outside of the argument of whether or not NULLs should ever be used: I am responsible for an existing database that uses NULL to mean "missing or never entered" data. It is different from empty string, which means "a user set this value, and they selected 'empty'." Another contractor on the project is firmly on the "NULLs do not exist for me; I never use NULL and nobody else should, either" side of the argument. However, what confuses me is that since the contractor's team DOES acknowledge

Is there any way to get the column name along with the output while execute any query in Hive?

南笙酒味 提交于 2019-11-30 10:17:01
问题 In Hive, when we do a query (like: select * from employee ), we do not get any column names in the output (like name, age, salary that we would get in RDBMS SQL ), we only get the values. Is there any way to get the column names to be displayed along with the output when you execute any query? 回答1: If we want to see the columns names of the table in HiveQl, the following hive conf property should be set to true. hive> set hive.cli.print.header=true; If you prefer to see the column names

SQL query for point-in-polygon using PostgreSQL

孤人 提交于 2019-11-30 07:28:53
问题 I have the following simple table: CREATE TABLE tbl_test ( id serial NOT NULL, poly polygon NOT NULL ) WITH (OIDS=FALSE); I then try to insert a row with a polygon: insert into tbl_test values(1, PolyFromText('POLYGON((0 0, 10 10, 10 0, 0 0))')) And run into this error: column "poly" is of type polygon but expression is of type geometry Which is lame. So my first questions is: Do I really have to cast? Anyway, after casting it works. And now I'm trying to do a simple ST_Contains query: select

Hadoop comparison to RDBMS

别说谁变了你拦得住时间么 提交于 2019-11-30 07:16:29
问题 I really do not understand the actual reason behind hadoop scaling better than RDBMS . Can anyone please explain at a granular level ? Has this got something to do with underlying datastructures & algorithms 回答1: RDBMS have challenges in handling huge data volumes of Terabytes & Peta bytes. Even if you have Redundant Array of Independent/Inexpensive Disks (RAID) & data shredding, it does not scale well for huge volume of data. You require very expensive hardware. EDIT: To answer, why RDBMS

Why have object oriented databases not been successful (yet)? [closed]

强颜欢笑 提交于 2019-11-30 06:12:01
That's the question. Give only one reason you think why have OODB failed or why many systems nowadays still use relational databases. Can we answer more than once? Another reason is that relational DB's have a strong foundation in mathematics: from the definition of a relation, right through to the normal forms, the theory is rock solid. It is true that the relational model does not map well to OO, but IMHO the benefits and stability of that model outweigh the mapping problem. Phil Bennett The main reason is SQL. It is very useful to be able to use the data from a database in other contexts

Why would I ever choose to store and manipulate XML in a relational database?

旧时模样 提交于 2019-11-30 05:55:37
问题 Modern RDBMS's have support for XML column types and functionality for dealing with XML in stored procedures. Historically I would always have mapped hierarchical data (whether of OO objects or XML) to relational tables. Given the widespread database support for XML should I change my ways? 回答1: If you don't see the need then don't change! Sometimes you have to persist data that does not have a known structure, or its structure is very volatile. In those cases, instead of creating a table,