Im getting netflow data from multiples machines using filebeat, one of the fields I get is netflow.application_id and I need to transate the Id to the name of the application, the format of the application_id is this:
3, 0, 1, 244
four comma separated values.
how I can translate the id to a name?
is there a dictionary out there?
Thanks!
What you could do is use a script processor to split the values in the network.application_id field and then do a lookup to append the values accordingly. This is definitely an option, but not necessarily the only option. Feel free to accept this answer if it works for you.
Related
If I have a field that includes many values like
67495837431978432 ABC1234
and other values like
1234 Something Street
(I know the data shouldn't be like this. It isn't my database. Can't be changed. Please disregard.)
How can I only return records that have data in this field like the former?
I've tried
where SUBSTRING(field, 1, 10) LIKE '%[0-9]%'
with my thought being if the first type of value starts with 17 numbers, and the next type is a street address with many letters in the first 10 characters, I should be able to check if the first 10 characters only include numbers, and return the field based on that, and I should only get back records like
67495837431978432 ABC1234
as I desire to. Not the cleanest, but should work fine for my situation. But that didn't work. I can't see why. Am I making an error I'm not seeing? Is there a better way to do this that is relatively simple?
If you are using SQL Server and you want to check that the first ten characters are digits, you can use like with character classes:
where field LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]%'
I have a column of type bigint (ProductSerial) in my table. I need to filter the table by the Product serial using like operator. But I found that, like operator can't be used for integer type.
Is there any other method for this (I don't want to use the = operator).
If you must use LIKE, you can cast your number to char/varchar, and perform the LIKE on the result. This is quite inefficient, but since LIKE has a high potential of killing indexes anyway, it may work in your scenario:
... AND CAST(phone AS VARCHAR(9)) LIKE '%0203'
If you are looking to use LIKE to match the beginning or the end of the number, you could use integer division and modulus operators to extract the digits. For example, if you want all nine-digit numbers starting in 407, search for
phone / 1000000 = 407
Although I'm a bit late to the party, I'd like to add the method I'm using to match the first N given numbers (in the example, 123) in any numeric-type column:
SELECT * FROM MyTable WHERE MyColumn / POWER(10, LEN(MyColumn) - LEN(123)) = 123
The technique is similar to #dasblinkenlight's one, but it works regardless of the number of digits of the target column values. This is a viable workaround if your column contain numbers with different length and you don't want to use the CAST+LIKE method (or a calculated column).
For additional details on that (and other LIKE workarounds) check out this blog post that I wrote on this topic.
If you have control over the database you could add a calculated column to copy the integer value to a string:
ALTER TABLE MyTable
ADD CalcCol AS (CAST(ProductSerial AS VARCHAR)) PERSISTED
And query like:
SELECT *
FROM MyTable
WHERE ProductSerial LIKE '%2548%'
This will move the calculation to the insert/update and only on rows inserted/updated rather then converting every row for each query.
This may be a problem if there are a lot of updated to columns as it will add a very small overhead to these.
There may be a way to do it mathematically using modulus but this would take a lot of working out and testing.
You can change your Field PhoneNumbers and store as String and then use the Like You can alter your table so that you can use the LIKE statement, if you still want to use BIGint for your phone numbers, you cannot get the exact Phone Number without using = the method you can use is Between method that looks for the Numbers that are inside the range.
For the edited question: I think you should use = sign for their ID, or convert the Int to String and then Use Like.
The original question related to a phone number. OP has since edited it to refer to serial numbers. This answer refers to the original question only.
My suggestion is to avoid storing your phone numbers as integers in the first place, and thus the problem does not occur. My phone number is in the form, internationally, of:
+44 7844 51515
Storing it as an integer makes no sense here, as you will never need to do any mathematical operation on it, and you would lose the leading plus. Within the UK, it is:
07844 51515
and thus storing it as an integer would lose its leading zero. Unless you have a very very specific requirement to store it as an integer, you would fare significantly better storing it as a string instead.
[Note: Not actually my phone number]
I have two tables that I'd like to join via the MAC Address field, but each table stores MAC addresses slightly different:
Table 1 data: 0:1e:8:c5:9e:fe
Table 2 data: 00:1e:08:c5:9e:fe
The first one removes starting 0's for ANY of the 6 groups of colon-separated fields.
Is there a way I can join on these in SQL without having to modify the data?
I'm guessing I would have to convert both values to XX:XX:XX:XX:XX:XX, then compare them...I'm just not quite sure how to do that.
You can remove leading zeroes with the REPLACE and STUFF functions:
SELECT *
FROM Table1
INNER JOIN Table2
ON Table1.ShortMac = STUFF(REPLACE(':' + Table2.LongMac, ':0', ':'), 1, 1, '')
Unfortunately, no, they cannot be joined without modifying the data in some way.
I would avoid using the MAC addresses as primary keys since they can change.
If you must use them, is it possible to ensure they're all being inserted in a consistent format? Once that's taken care of, you could write a script (whether it's in SQL, or using another language in an application that can interface with the db) to update all of your existing records to a consistent format. You can just split them apart at a delimiter like the ':' and code to pad a 0 if needed. This would allow you to do your joins without having to create any sort of conversion methods.
Simple way to convert the values would be to split or tokenize the string on the :. Then loop over the items and if size != 2, prepend a 0, and then concatenate them back together. Kinda brute force, but it'd do the job.
Similar to a brute force approach like #plattitude describes but somewhat simpler you could use a regular expresion and REPLACE where each ':' character matches either ':' or ':0' and the shorter string or '0'+ the shorter string matches the longer.
Sorry in hotel room with no access to build and test expression but someone may like to add it to the answer.
With regards to Performance & 'The proper way of doing things' and trying to figure out which way is better to store configuration data in a SQL database. Assume you have website configuration data for setting a minimum and maximum age that a person must be to access the site.
CREATE TABLE SiteConfig
(
featureName varchar(100),
value varchar(100),
)
Which is better:
To store it all in a single row and process it in PHP with explode();.
featureName: "ageRequirement"
value: "13|60"
To store it in separate rows for each feature and just SELECT the feature you need when needed.
featureName: "minAge"
value: "13"
featureName: "maxAge"
value: "60"
Due to the amount of features of the website, this is a difference of having 60 ROWS of data vs. about 25.
Store it has two separate features.
You may want to access the feature in the database, rather than in the application code.
There is no reason to parse a comma delimited string to get two features.
Admittedly, in the case of just two numbers separated by a comma, not much can go wrong. This is, however, a slippery slope and you might soon find yourself trying to stuff multiple fields into a single string, and then devoting a lot of resources to parsing the string.
If those are values that you never will use by themselves in the database, either would work.
If you suspect that you would ever want to use the value in the database, you would not want them in the same value. That would make querying the data complicated and inefficient.
I'm trying to write an SQL query that would search within a CSV (or similar) array in a column. Here's an example:
insert into properties set
bedrooms = 1,2,3 (or 1-3)
title = nice property
price = 500
I'd like to then search where bedrooms = 2+. Is this even possible?
The correct way to handle this in SQL is to add another table for a multi-valued property. It's against the relational model to store multiple discrete values in a single column. Since it's intended to be a no-no, there's little support for it in the SQL language.
The only workaround for finding a given value in a comma-separated list is to use regular expressions, which are in general ugly and slow. You have to deal with edge cases like when a value may or may not be at the start or end of the string, as well as next to a comma.
SELECT * FROM properties WHERE bedrooms RLIKE '[[:<:]]2[[:>:]]';
There are other types of queries that are easy when you have a normalized table, but hard with the comma-separated list. The example you give, of searching for a value that is equal to or greater than the search criteria, is one such case. Also consider:
How do I delete one element from a comma-separated list?
How do I ensure the list is in sorted order?
What is the average number of rooms?
How do I ensure the values in the list are even valid entries? E.g. what's to prevent me from entering "1,2,banana"?
If you don't want to create a second table, then come up with a way to represent your data with a single value.
More accurately, I should say I recommend that you represent your data with a single value per column, and Mike Atlas' solution accomplishes that.
Generally, this isn't how you should be storing data in a relational database.
Perhaps you should have a MinBedroom and MaxBedroom column. Eg:
SELECT * FROM properties WHERE MinBedroom > 1 AND MaxBedroom < 3;