In the example below how to add the formula in individual user totals as the number of rows for the user can vary.
+------+--------------+---------+--------------+-------+
| Name | Date | Billable| Non-Billable | Total |
+------+--------------+---------+--------------+-------+
| abc | 06/23/2012 | 860 | 10 | 870 |
| | User Totals: | 860 | 10 | 870 |
| xyz | 07/12/2012 | 45 | 0 | 45 |
| | User Totals: | 45 | 0 | 45 |
| ccc | 09/19/2013 | 165 | 35 | 200 |
| | 10/15/2013 | 240 | 0 | 240 |
| | User Totals: | 405 | 35 | 440 |
| | Grand Totals | 1310| 45 | 1355 |
+------+--------------+---------+--------------+-------+
Related
Single-job schedule with two vehicles. One vehicle starts close to the job, the other starts far from the job. Seems it should prefer to use the closer vehicle, as there's a cost-per-distance. But it uses the farther one, if there's a non-zero setCostPerWaitingTime(). Why?
public void testUseCloserVehicleWhenCostsAreSet() throws Exception {
VehicleType type = VehicleTypeImpl.Builder.newInstance("generic")
.setCostPerDistance(0.017753)
//.setCostPerTransportTime(1.0)
.setCostPerWaitingTime(1.0)
.build();
double serviceTime = 420.0;
Location pointA = Location.newInstance(100.0, 100.0);
Location pointB = Location.newInstance(100.0, 200.0);
Location closeToPointA = Location.newInstance(110.0, 110.0);
Location farFromPointA = Location.newInstance(500.0, 110.0);
VehicleRoutingProblem vrp = VehicleRoutingProblem.Builder
.newInstance()
.setFleetSize(VehicleRoutingProblem.FleetSize.FINITE)
.addVehicle(VehicleImpl.Builder.newInstance("CloseBy")
.setType(type)
.setStartLocation(closeToPointA)
.build())
.addVehicle(VehicleImpl.Builder.newInstance("FarAway")
.setType(type)
.setStartLocation(farFromPointA)
.build())
.addJob(Shipment.Builder.newInstance("123")
.setPickupLocation(pointA)
.setPickupServiceTime(serviceTime)
.setDeliveryLocation(pointB)
.setDeliveryServiceTime(serviceTime)
.setPickupTimeWindow(new TimeWindow(36000.0, 36360.0))
.setDeliveryTimeWindow(new TimeWindow(36360.0, 36720.0))
.setMaxTimeInVehicle(720.0)
.build())
.build();
VehicleRoutingAlgorithm algorithm = Jsprit.Builder.newInstance(vrp)
.buildAlgorithm();
VehicleRoutingProblemSolution bestSolution = Solutions.bestOf(algorithm.searchSolutions());
SolutionPrinterWithTimes.print(vrp, bestSolution, SolutionPrinterWithTimes.Print.VERBOSE);
System.out.flush();
assertEquals("CloseBy", bestSolution.getRoutes().iterator().next().getVehicle().getId());
}
Result:
+----------------------------------------------------------+
| solution |
+---------------+------------------------------------------+
| indicator | value |
+---------------+------------------------------------------+
| costs | 35616.03246830352 |
| noVehicles | 1 |
| unassgndJobs | 0 |
+----------------------------------------------------------+
+--------------------------------------------------------------------------------------------------------------------------------+
| detailed solution |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| route | vehicle | activity | job | arrTime | endTime | costs |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| 1 | FarAway | start | - | undef | 0 | 0 |
| 1 | FarAway | pickupShipment | 123 | 400 | 36420 | 35607 |
| 1 | FarAway | deliverShipment | 123 | 36520 | 36940 | 35609 |
| 1 | FarAway | end | - | 37350 | undef | 35616 |
+--------------------------------------------------------------------------------------------------------------------------------+
junit.framework.ComparisonFailure:
Expected :CloseBy
Actual :FarAway
I suspect it has something to do with the vehicle arriving at 400 for a job that can't start until 36000. Is there a way to prevent that, so the vehicle starts only as early as needed to reach the first job? Does setCostPerWaitingTime do something other than what I think?
Here's a comparison of the job with only the CloseBy vehicle.
+--------------------------------------------------------------------------------------------------------------------------------+
| detailed solution |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| route | vehicle | activity | job | arrTime | endTime | costs |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| 1 | FarAway | start | - | undef | 0 | 0 |
| 1 | FarAway | pickupShipment | 123 | 400 | 36420 | 35607 |
| 1 | FarAway | deliverShipment | 123 | 36520 | 36940 | 35609 |
| 1 | FarAway | end | - | 37350 | undef | 35616 |
+--------------------------------------------------------------------------------------------------------------------------------+
+--------------------------------------------------------------------------------------------------------------------------------+
| detailed solution |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| route | vehicle | activity | job | arrTime | endTime | costs |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| 1 | CloseBy | start | - | undef | 0 | 0 |
| 1 | CloseBy | pickupShipment | 123 | 14 | 36420 | 35986 |
| 1 | CloseBy | deliverShipment | 123 | 36520 | 36940 | 35988 |
| 1 | CloseBy | end | - | 37031 | undef | 35989 |
+--------------------------------------------------------------------------------------------------------------------------------+
I think the problem is that the CloseBy vehicle arrives sooner, so it pays higher wait costs, while the other vehicle is driving during that time so pays less in wait costs. This would be mitigated if the vehicle didn't start until it needed to, but I'm unsure how to set that up.
I have a task to take a look in a database (SAP iDoc) that has specific values in it derived by segments. I have to export an xml at the end of the mapping that has a subcomponent that can have more than one row. My problem is that we have a component that has two values that are separated by a qualifier.
Every transaction looks like so:
+----------+-----------+--------+
| QUALF_1 | BETRG_dc | DOCNUM |
+----------+-----------+--------+
| 001 | 20 | xxxxxx |
| 001 | 22 | xxxxxx |
+----------+-----------+--------+
+---------+-----------+-----------+
| QUALF_2 | BETRG_pr | DOCNUM |
+---------+-----------+-----------+
| 013 | 30 | xxxxxx |
| 013 | 40 | xxxxxx |
+---------+-----------+-----------+
My problem is that when joined with the built in transformations we have a geometrical progression like so
+---------+-----------+-----------+
| DOCNUM | BETRG_dc | BETRG_pr |
+---------+-----------+-----------+
| xxxxxx | 20 | 30 |
| xxxxxx | 20 | 40 |
| xxxxxx | 22 | 30 |
| xxxxxx | 22 | 40 |
+---------+-----------+-----------+
As you can see only the first and last rows are correct.
The problem comes from the fact that if BETRG_dc is 0 the whole segment is not being sent so a filter transformation fails.
What i found out is the the segment number of QUALF_1 and QUALF_2 are sequencial. So QUALF_1 is for example 48 and QUALF_2 is 49.
Can you help me create a JAVA transformation that adds a row for a missing QUALF_1.
Here is a table of requirements:
+-------+-------+---------------+
| QUALF | BETRG | SegmentNumber |
+-------+-------+---------------+
| 013 | 20 | 48 |
| 001 | 150 | 49 |
| 013 | 15 | 57 |
| 001 | 600 | 58 |
+-------+-------+---------------+
I want the transformation to take a look and if we have a source like this:
+-------+-------+---------------+
| QUALF | BETRG | SegmentNumber |
+-------+-------+---------------+
| 001 | 150 | 49 |
| 013 | 15 | 57 |
| 001 | 600 | 58 |
+-------+-------+---------------+
To go ahead and insert a row with the segment id 48 and a value for BETRG of "0".
I have tried every transformation i can.
The expected output should be like this:
+-------+-------+---------------+
| QUALF | BETRG | SegmentNumber |
+-------+-------+---------------+
| 013 | 0 | 48 |
| 001 | 150 | 49 |
| 013 | 15 | 57 |
| 001 | 600 | 58 |
+-------+-------+---------------+
You should join both of the table in a joiner transformation.
use Left(master) outer join and then take it into a target. then map the BETRG column from the right table to the target and the rest of the columns from the left table.
what happens is when ever there is no match BETRG will be empty. take it into a expression and see if the value is null or empty and change it to 0 or what value you wish.
Here is what i have created but unfortunately for now it works on a row level only and not on the whole data. I am working on making the code run properly:
QUALF_out = QUALF;
BETRG_out= BETRG;
SegmentNumber_out= SegmentNumber;
if(QUALF.equals("001"))
{
segment_new=(SegmentNumber - 1);
}
int colCount=1;
myList.add(SegmentNumber);
System.out.println("SegmentNumber_out: " + segment_new);
if(Arrays.asList(myList).contains(segment_new)){
QUALF_out = QUALF;
BETRG_out= BETRG;
SegmentNumber_out= SegmentNumber;
QUALF_out="013";
BETRG_out="0";
SegmentNumber_out=segment_new;
generateRow();
} else {
QUALF_out = QUALF;
BETRG_out= BETRG;
SegmentNumber_out= SegmentNumber;
generateRow();
}
Here is what works:
import java.util.*;
private ArrayList<String> myList2 = new ArrayList<String>();
QUALF_out = QUALF;
BETRG_out = BETRG;
SegmentNumber_out = SegmentNumber;
DOCNUM = DOCNUM;
array_for_search = QUALF + ParentSegmentNumber + DOCNUM ;
myList2.add(array_for_search);
System.out.println("myList: " + myList2);
System.out.println("Array: " + myList2.contains("910" + ParentSegmentNumber + DOCNUM));
if(!myList2.contains("910" + ParentSegmentNumber + DOCNUM)){
QUALF_out="910";
BETRG_out="0";
}
generateRow();
I create a temp table which consist of several table with UNION ALL statement like here below. I want later map this table to the entity for repository in spring. With other words I wanna map temp table to entity in spring jpa or hibernate.
select * from name UNION ALL
select * from soft where id >3
into temp namesoft_tmp
I tried the following.
select * from namesoft_tmp
but i can't see what is the column which can point me to the conclusion that this is primary key.
What is the unique id(primary key) of table namesoft_tmp?
How can i add auto generated id to temp table?
How can i excute select statement based on unique id?**
In general, the result of a UNION ALL query does not have a primary key; there is no guarantee that there are not duplicate rows in the result set.
Imagine a table describing the table of elements — called elements.
SELECT * FROM elements WHERE atomic_number < 10
UNION ALL
SELECT * FROM elements WHERE symbol MATCHES '[A-F]*'
INTO TEMP union_all;
Here, the elements Boron (B), Carbon (C), Beryllium (Be) and Fluorine (F) are all listed twice.
However, you can use:
SELECT ROWID, * FROM union_all ORDER BY atomic_number;
to get a unique identifier, the ROWID, in the result set. Note that this unique identifier is unique at any given time, but is not guaranteed to be stable. If you delete rows and add them again, the ROWID of the replaced rows may be different from before. But the ROWID will be unique until you edit the table.
+-------+--------+--------+--------------+-----------+--------+-------+
| rowid | atomic | symbol | name | atomic | period | group |
| | number | | | weight | | |
+-------+--------+--------+--------------+-----------+--------+-------+
| 257 | 1 | H | Hydrogen | 1.0079 | 1 | 1 |
| 258 | 2 | He | Helium | 4.0026 | 1 | 18 |
| 259 | 3 | Li | Lithium | 6.9410 | 2 | 1 |
| 260 | 4 | Be | Beryllium | 9.0122 | 2 | 2 |
| 266 | 4 | Be | Beryllium | 9.0122 | 2 | 2 |
| 267 | 5 | B | Boron | 10.8110 | 2 | 13 |
| 261 | 5 | B | Boron | 10.8110 | 2 | 13 |
| 268 | 6 | C | Carbon | 12.0110 | 2 | 14 |
| 262 | 6 | C | Carbon | 12.0110 | 2 | 14 |
| 263 | 7 | N | Nitrogen | 14.0070 | 2 | 15 |
| 264 | 8 | O | Oxygen | 15.9990 | 2 | 16 |
| 265 | 9 | F | Fluorine | 18.9980 | 2 | 17 |
| 269 | 9 | F | Fluorine | 18.9980 | 2 | 17 |
| 270 | 13 | Al | Aluminium | 26.9820 | 3 | 13 |
| 271 | 17 | Cl | Chlorine | 35.4530 | 3 | 17 |
| 272 | 18 | Ar | Argon | 39.9480 | 3 | 18 |
| 273 | 20 | Ca | Calcium | 40.0780 | 4 | 2 |
| 274 | 24 | Cr | Chromium | 51.9960 | 4 | 6 |
| 275 | 26 | Fe | Iron | 55.8450 | 4 | 8 |
| 276 | 27 | Co | Cobalt | 58.9330 | 4 | 9 |
| 277 | 29 | Cu | Copper | 63.5460 | 4 | 11 |
| 278 | 33 | As | Arsenic | 74.9220 | 4 | 15 |
| 279 | 35 | Br | Bromine | 79.9040 | 4 | 17 |
| 280 | 47 | Ag | Silver | 107.8700 | 5 | 11 |
| 281 | 48 | Cd | Cadmium | 112.4100 | 5 | 12 |
| 282 | 55 | Cs | Caesium | 132.9100 | 6 | 1 |
| 283 | 56 | Ba | Barium | 137.3300 | 6 | 2 |
| 284 | 58 | Ce | Cerium | 140.1200 | 6 | L |
| 285 | 63 | Eu | Europium | 151.9600 | 6 | L |
| 286 | 66 | Dy | Dyprosium | 162.5000 | 6 | L |
| 287 | 68 | Er | Erbium | 167.2600 | 6 | L |
| 288 | 79 | Au | Gold | 196.9700 | 6 | 11 |
| 289 | 83 | Bi | Bismuth | 208.9800 | 6 | 15 |
| 290 | 85 | At | Astatine | 209.9900 | 6 | 17 |
| 291 | 87 | Fr | Francium | 223.0200 | 7 | 1 |
| 292 | 89 | Ac | Actinium | 227.0300 | 7 | A |
| 293 | 95 | Am | Americium | 243.0600 | 7 | A |
| 294 | 96 | Cm | Curium | 247.0700 | 7 | A |
| 295 | 97 | Bk | Berkelium | 247.0700 | 7 | A |
| 296 | 98 | Cf | Californium | 251.0800 | 7 | A |
| 297 | 99 | Es | Einsteinium | 252.0800 | 7 | A |
| 298 | 100 | Fm | Fermium | 257.1000 | 7 | A |
| 299 | 105 | Db | Dubnium | 270.1300 | 7 | 5 |
| 300 | 107 | Bh | Bohrium | 270.1300 | 7 | 7 |
| 301 | 110 | Ds | Darmstadtium | 281.1700 | 7 | 10 |
| 302 | 112 | Cn | Copernicium | 285.1800 | 7 | 12 |
| 303 | 114 | Fl | Flerovium | 289.1900 | 7 | 14 |
+-------+--------+--------+--------------+-----------+--------+-------+
I've a query that has a quite strange behavior (I cannot show it all, it's quite long and with various joins).
Inside the query I've a test over a value (a number) like this:
AND (
R.CAPACITY IS NULL
OR
R.CAPACITY = 0
OR
(R.CAPACITY BETWEEN :minSeats AND :maxSeats)
)
It works without any problem. It is fast, when I ran it directly from IDE (I use IDEA) as when I run it from code (tests or triggering it from the interface).
What I don't understand is that, if the first two conditions
R.CAPACITY IS NULL
OR
R.CAPACITY = 0
are removed the query becomes extremely slow. Not everywhere, because in IDEA it is still quite fast. But, from code it's impossible to use it.
I've tried to change the data on the database, to create (changing the data) indexes, to change the WHERE condition with a JOIN where the data is filtered by this conditions. No way. Nothing works. It's always really fast (as expected, by the way) in IDEA but slow, too much slow, in code. I run it against an Oracle DB (version 9).
Strange is also that the field has no NULL values, but to be fast the query requires a check against them.
Has anyone idea why this happens?
EDIT (sorry, I've switched the plans)
Explain plan of FAST query is:
Plan hash value: 3802388129
---------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 7 | 1463 | 1887 (8)| 00:00:23 |
| 1 | SORT UNIQUE | | 7 | 1463 | 1886 (8)| 00:00:23 |
|* 2 | HASH JOIN OUTER | | 7 | 1463 | 1885 (8)| 00:00:23 |
| 3 | VIEW | | 7 | 1288 | 754 (10)| 00:00:10 |
|* 4 | HASH JOIN | | 7 | 2891 | 754 (10)| 00:00:10 |
|* 5 | HASH JOIN OUTER | | 7 | 2688 | 750 (10)| 00:00:10 |
| 6 | NESTED LOOPS | | 7 | 476 | 750 (10)| 00:00:09 |
| 7 | NESTED LOOPS | | 7 | 147 | 743 (10)| 00:00:09 |
|* 8 | INDEX UNIQUE SCAN | DATUM_U1 | 1 | 8 | 1 (0)| 00:00:01 |
| 9 | VIEW | VW_NSO_1 | 7 | 91 | 742 (10)| 00:00:09 |
|* 10 | FILTER | | | | | |
| 11 | SORT GROUP BY | | 7 | 189 | 742 (10)| 00:00:09 |
| 12 | MERGE JOIN CARTESIAN | | 1170K| 30M| 679 (2)| 00:00:09 |
| 13 | MERGE JOIN CARTESIAN | | 2808 | 53352 | 54 (0)| 00:00:01 |
|* 14 | TABLE ACCESS FULL | TABLEA | 108 | 1728 | 29 (0)| 00:00:01 |
| 15 | BUFFER SORT | | 26 | 78 | 25 (0)| 00:00:01 |
| 16 | INDEX FAST FULL SCAN| SYS_C0012272 | 26 | 78 | 0 (0)| 00:00:01 |
| 17 | BUFFER SORT | | 417 | 3336 | 742 (10)| 00:00:09 |
| 18 | INDEX FAST FULL SCAN | SYS_C0012270 | 417 | 3336 | 0 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID| TABLEA | 1 | 47 | 1 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | SYS_C0012267 | 1 | | 0 (0)| 00:00:01 |
| 21 | VIEW | | 1 | 316 | 5 (100)| 00:00:01 |
|* 22 | FILTER | | | | | |
| 23 | MERGE JOIN CARTESIAN | | 595 | 98K| 10 (0)| 00:00:01 |
| 24 | VIEW | index$_join$_006 | 5 | 445 | 3 (0)| 00:00:01 |
|* 25 | HASH JOIN | | | | | |
| 26 | INDEX FAST FULL SCAN | TABLEB | 5 | 445 | 1 (0)| 00:00:01 |
| 27 | INDEX FAST FULL SCAN | TABLEC | 5 | 445 | 1 (0)| 00:00:01 |
| 28 | BUFFER SORT | | 119 | 9520 | 7 (0)| 00:00:01 |
| 29 | TABLE ACCESS FULL | TABLED | 119 | 9520 | 1 (0)| 00:00:01 |
| 30 | TABLE ACCESS FULL | TABLEE | 28 | 812 | 3 (0)| 00:00:01 |
| 31 | VIEW | | 1636 | 40900 | 1130 (7)| 00:00:14 |
|* 32 | FILTER | | | | | |
|* 33 | HASH JOIN | | 3845K| 245M| 1130 (7)| 00:00:14 |
|* 34 | TABLE ACCESS FULL | TABLEF | 106 | 1378 | 12 (9)| 00:00:01 |
| 35 | NESTED LOOPS | | 290K| 14M| 1096 (5)| 00:00:14 |
|* 36 | TABLE ACCESS FULL | TABLEG | 290K| 13M| 1064 (2)| 00:00:13 |
|* 37 | INDEX UNIQUE SCAN | PK_TABLEH | 1 | 5 | 0 (0)| 00:00:01 |
|* 38 | TABLE ACCESS BY INDEX ROWID | TABLEG | 1 | 36 | 5 (0)| 00:00:01 |
|* 39 | INDEX RANGE SCAN | TABLEI | 3 | | 3 (0)| 00:00:01 |
|* 40 | TABLE ACCESS BY INDEX ROWID | TABLEG | 1 | 36 | 5 (0)| 00:00:01 |
|* 41 | INDEX RANGE SCAN | TABLEI | 3 | | 3 (0)| 00:00:01 |
|* 42 | TABLE ACCESS FULL | TABLEL | 1 | 23 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------
Plan of SLOW query:
Plan hash value: 453029505
---------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 434 | 1348 (7)| 00:00:17 |
| 1 | SORT UNIQUE | | 2 | 434 | 1347 (7)| 00:00:17 |
|* 2 | HASH JOIN OUTER | | 2 | 434 | 1346 (7)| 00:00:17 |
| 3 | VIEW | | 2 | 384 | 215 (9)| 00:00:03 |
| 4 | NESTED LOOPS | | 2 | 826 | 215 (9)| 00:00:03 |
|* 5 | HASH JOIN OUTER | | 2 | 768 | 213 (9)| 00:00:03 |
| 6 | NESTED LOOPS | | 2 | 136 | 212 (9)| 00:00:03 |
| 7 | NESTED LOOPS | | 2 | 42 | 210 (9)| 00:00:03 |
|* 8 | INDEX UNIQUE SCAN | DATUM_U1 | 1 | 8 | 1 (0)| 00:00:01 |
| 9 | VIEW | VW_NSO_1 | 2 | 26 | 209 (9)| 00:00:03 |
|* 10 | FILTER | | | | | |
| 11 | SORT GROUP BY | | 2 | 58 | 209 (9)| 00:00:03 |
| 12 | MERGE JOIN CARTESIAN | | 291K| 8252K| 194 (2)| 00:00:03 |
| 13 | MERGE JOIN CARTESIAN | | 699 | 14679 | 37 (0)| 00:00:01 |
|* 14 | TABLE ACCESS FULL | TABLEA | 27 | 486 | 29 (0)| 00:00:01 |
| 15 | BUFFER SORT | | 26 | 78 | 8 (0)| 00:00:01 |
| 16 | INDEX FAST FULL SCAN| SYS_C0012272 | 26 | 78 | 0 (0)| 00:00:01 |
| 17 | BUFFER SORT | | 417 | 3336 | 209 (9)| 00:00:03 |
| 18 | INDEX FAST FULL SCAN | SYS_C0012270 | 417 | 3336 | 0 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID| TABLEA | 1 | 47 | 1 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | SYS_C0012267 | 1 | | 0 (0)| 00:00:01 |
| 21 | VIEW | | 1 | 316 | 5 (100)| 00:00:01 |
|* 22 | FILTER | | | | | |
| 23 | MERGE JOIN CARTESIAN | | 595 | 98K| 10 (0)| 00:00:01 |
| 24 | VIEW | index$_join$_006 | 5 | 445 | 3 (0)| 00:00:01 |
|* 25 | HASH JOIN | | | | | |
| 26 | INDEX FAST FULL SCAN | TABLEB | 5 | 445 | 1 (0)| 00:00:01 |
| 27 | INDEX FAST FULL SCAN | TABLEC | 5 | 445 | 1 (0)| 00:00:01 |
| 28 | BUFFER SORT | | 119 | 9520 | 7 (0)| 00:00:01 |
| 29 | TABLE ACCESS FULL | TABLED | 119 | 9520 | 1 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID | TABLEE | 1 | 29 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | SYS_C0012290 | 1 | | 0 (0)| 00:00:01 |
| 32 | VIEW | | 1636 | 40900 | 1130 (7)| 00:00:14 |
|* 33 | FILTER | | | | | |
|* 34 | HASH JOIN | | 3845K| 245M| 1130 (7)| 00:00:14 |
|* 35 | TABLE ACCESS FULL | TABLEF | 106 | 1378 | 12 (9)| 00:00:01 |
| 36 | NESTED LOOPS | | 290K| 14M| 1096 (5)| 00:00:14 |
|* 37 | TABLE ACCESS FULL | TABLEG | 290K| 13M| 1064 (2)| 00:00:13 |
|* 38 | INDEX UNIQUE SCAN | PK_TABLEH | 1 | 5 | 0 (0)| 00:00:01 |
|* 39 | TABLE ACCESS BY INDEX ROWID | TABLEG | 1 | 36 | 5 (0)| 00:00:01 |
|* 40 | INDEX RANGE SCAN | TABLEI | 3 | | 3 (0)| 00:00:01 |
|* 41 | TABLE ACCESS BY INDEX ROWID | TABLEG | 1 | 36 | 5 (0)| 00:00:01 |
|* 42 | INDEX RANGE SCAN | TABLEI | 3 | | 3 (0)| 00:00:01 |
|* 43 | TABLE ACCESS FULL | TABLEL | 1 | 23 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------
I have generated an encrypted token from Blowfish. Eg:- 7$127O$137kI$137mK$07WK$01$26m$05zYbJmCmUw$16nF$11G$27A2Gv$19Jm8$26eJ9kUv$07$118q$05$02$24KP8j$208$16$06$100P$11
Just out of curiosity , can I get this token more minimized/simplify/striped somehow. Can anything to be done in order to get this more so simplified , may be any encoding. Please help me out with this.
Thanks
Huffman has a static cost, the Huffman table. On the other side, algorithms of the Lempel-Ziv family have very good compression and performance.
If your string is going to be english text you better use Smaz: https://github.com/antirez/smaz/tree/master
Try Huffman encoding with your string. For the string 7$127O$137kI$137mK$07WK$01$26m$05zYbJmCmUw$16nF$11G$27A2Gv$19Jm8$26eJ9kUv$07$118q$05$02$24KP8j$208$16$06$100P$11
the compression ratio is 0.536830357143.
Analysis
Memory requirements: ASCII: 896 bit , Huffman: 593 bit
Entropy: ASCII: 1.01833029706, Huffman: 1.05223637886
Average code length: ASCII: 8 bit , Huffman: 4.29464285714 bit
Compression rate: 0.536830357143
+---------+-------+-------+-----------+---------+---------+
| Seq.no. | Chars | ASCII | Frequency | Huffman | ASCII |
+---------+-------+-------+-----------+---------+---------+
| 0 | '$' | 36 | 22 | 0 | 100100 |
| 1 | '0' | 48 | 10 | 1111 | 110000 |
| 2 | '1' | 49 | 14 | 11 | 110001 |
| 3 | '2' | 50 | 8 | 1011 | 110010 |
| 4 | '3' | 51 | 2 | 110100 | 110011 |
| 5 | '4' | 52 | 1 | 101111 | 110100 |
| 6 | '5' | 53 | 2 | 111001 | 110101 |
| 7 | '6' | 54 | 5 | 100 | 110110 |
| 8 | '7' | 55 | 7 | 1000 | 110111 |
| 9 | '8' | 56 | 4 | 11011 | 111000 |
| 10 | '9' | 57 | 2 | 110011 | 111001 |
| 11 | 'A' | 65 | 1 | 1100001 | 1000001 |
| 12 | 'C' | 67 | 1 | 1100000 | 1000011 |
| 13 | 'F' | 70 | 1 | 1001100 | 1000110 |
| 14 | 'G' | 71 | 2 | 110101 | 1000111 |
| 15 | 'I' | 73 | 1 | 101110 | 1001001 |
| 16 | 'J' | 74 | 3 | 1010 | 1001010 |
| 17 | 'K' | 75 | 3 | 10010 | 1001011 |
| 18 | 'O' | 79 | 1 | 1010001 | 1001111 |
| 19 | 'P' | 80 | 2 | 110010 | 1010000 |
| 20 | 'U' | 85 | 2 | 101010 | 1010101 |
| 21 | 'W' | 87 | 1 | 1100010 | 1010111 |
| 22 | 'Y' | 89 | 1 | 1001101 | 1011001 |
| 23 | 'b' | 98 | 1 | 1010000 | 1100010 |
| 24 | 'e' | 101 | 1 | 1100011 | 1100101 |
| 25 | 'j' | 106 | 1 | 10110 | 1101010 |
| 26 | 'k' | 107 | 2 | 101001 | 1101011 |
| 27 | 'm' | 109 | 5 | 11101 | 1101101 |
| 28 | 'n' | 110 | 1 | 1001110 | 1101110 |
| 29 | 'q' | 113 | 1 | 1001111 | 1110001 |
| 30 | 'v' | 118 | 2 | 111000 | 1110110 |
| 31 | 'w' | 119 | 1 | 1010110 | 1110111 |
| 32 | 'z' | 122 | 1 | 1010111 | 1111010 |
+---------+-------+-------+-----------+---------+---------+