|
The name comes from the design concept - The Data Cloud | Snowflake[^] . It's surprisingly okay.
The azure bit though - I'm with you on that
|
|
|
|
|
Yes we use Snowflake but I'm not contacting you directly. Explain what your problem is and I will try to help
|
|
|
|
|
That goes against the idea of the website. You are asking for an employer, or an expert to consult. This is not a place to hire people.
Snowflake can't be that hard if it is just a shell around Azure; but you did not post a question about code - you specifically ask for someone to contact you for some vague crap.
Do that again and I'll vote as abuse; here we share questions and answers. If you're looking for an expert in a specific area and do not want to disclose the question, then you in the wrong place.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
My apologies. I hadn't seen anything on it in the forum. Just wanted to find out if there was anyone using it. I resolved the question that I had, after hammering around on it for several hours. I will ask in the proper place the next time.
|
|
|
|
|
You been regularly on this site, and you did not know we prefer questions over people recruiting?
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Not quite what I had in mind. Just wanted to see if there was anyone else using it. I have used SQL Server since it was created, and ran into a weird issue. If I hadn't figured it out, I would have posted a proper question.
|
|
|
|
|
Mike Ahrens wrote: Just wanted to see if there was anyone else using it No, you didn't, you asked specifically if they could contact you, without leaving a question.
Mike Ahrens wrote: If I hadn't figured it out, I would have posted a proper question. You did not post a question, but a vacancy. You could have found out by posting a question, which you did not.
Snowflake ain't that hard; but you looking here for something cheap, right?
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
"1"
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I have a sample table you can see here. This self-referencing table is used for creating a tree structure in an Angular project. I want to write a SQL query to create a JSON result with a parent-child structure. Please help me.
|
|
|
|
|
You can't use FOR JSON to generate recursive JSON documents. You'll need to create a recursive user-defined function instead.
CREATE OR ALTER FUNCTION dbo.fn_OrganizationJson(@ParentId int)
RETURNS nvarchar(max)
As
BEGIN
DECLARE @json nvarchar(max);
If @ParentId Is Null
BEGIN
SET @json = (SELECT Id, Name, dbo.fn_OrganizationJson(Id) As Children FROM dbo.Organizations WHERE ParentId Is Null FOR JSON AUTO);
END
Else
BEGIN
SET @json = (SELECT Id, Name, dbo.fn_OrganizationJson(Id) As Children FROM dbo.Organizations WHERE ParentId = @ParentId FOR JSON AUTO);
END
Return @json;
END
GO SQL Fiddle[^]
NB: In some versions of SQL, you can't create a function that refers to itself if the function doesn't already exists. You may need to CREATE FUNCTION first with a dummy body, and then ALTER FUNCTION to add the implementation.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Hi,
I want to write a program whose input is the names of the companies and when adding the name of each company, it will take various information from that company of different types,
1- TextBox (daily production rate),
2- CheckBox (select product features),
3- OptionButton (the gender of the company owner),
4- Date (Product delivery time, yy/mm/dd), ... in a form and store all that information in the profile of that company.
What programming language should I use for this task so that I can design a beautiful appearance (GUI) for entering information and this information can be entered easily by the user?
Is there a pre-written program that is close to my goal so that I can improve it to suit my needs?
Thanks in advance.
|
|
|
|
|
niksirat2030 wrote: What programming language should I use for this task so that I can design a beautiful appearance (GUI) for entering information and this information can be entered easily by the user?
You should use the language you know the best.
|
|
|
|
|
niksirat2030 wrote: What programming language should I use for this task so that I can design a beautiful appearance (GUI) for entering information and this information can be entered easily by the user? You are doing this back to front. You need to start with the business logic, and the data access. The front end can be beautied later, and if you want it to be really beautiful then employ a graphic designer.
|
|
|
|
|
niksirat2030 wrote: 3- OptionButton (the gender of the company owner),
Homework.
Do it.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
The language you use does not matter.
Your app "description" smells of homework. You're not going to find a "pre-written" program to do this. If you did, and you used it in your own app, and turned it in, you would get a failing grade.
|
|
|
|
|
I`m trying to understand how a data base file is different than an usual file (how data stored in a DB file is different than data saved in an usual file). Does the difference reside in the fact that in a data base file the data is saved in a fashion that reminds the method in which the OS is saving a HDD directory/folder tree (and that is by using tags)?
|
|
|
|
|
Calin Cali wrote: I`m trying to understand how a data base file is different than an usual file At the physical level it isn't. A file is just a collection of bytes stored (usually) on a physical device. The difference is how the software accesses the different parts of the file to enable it to be processed. A text file is just a single stream of characters using line end markers to separate the records. A database is a collection of tables that are structured by the database engine and accessed by various lookup methods. For the operating system the data remains just a collection of bytes that the DB engine accesses by logical addresses.
|
|
|
|
|
|
Not sure if it was paradox, but there was a database that stored each table as a file in a directory. It acted like a database, so no tree.
If I had to write a database-server, I'd start with reserving space, say 2Gb. The first Mb is used to name tables and find their location in that space. That's how lots of database-drivers and servers work; a server, like SQL Server would also reserve space for indexes and stored procedures.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Quote: It acted like a database, so no tree
Well yeah. The inner workings of the first (DB) is one thing the inner workings of the second (Directory tree) is something else, a DB doesn`t have to store data like a tree, or probably never stores data in a tree type structure. I assume the tables in your example were saved in the same folder and there was no creation of new folders and folder trees.
modified 21-Aug-22 9:07am.
|
|
|
|
|
You don't need to; even if the database file is a flat file, you can still define trees in the database.
SQL would not work nicely if tables could be structured like trees. You can still define your data as a tree in the db, no problem.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
>you can still define trees in a simple database file
I`ll take your word for that. It was the DB creating multiple files that me wondering how far it goes with that approach.
|
|
|
|
|
Calin Cali wrote: I`ll take your word for that. It was the DB creating multiple files that me wondering how far it goes with that approach. It doesn't; it abstracts away the idea of files. You could say it is a data abstraction layer
If you want a tree in a database, you create a database-relation between columns. SQL can account for that, not for files.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Quote: It doesn't
it doesn`t what? (no explicit question in my post)
Quote: it abstracts away the idea of files
If you ask me it`s not a DB job to abstract the idea of files. A DB usually is concerned with how the data is kept within a (single) file. Although interesting you DB marginal example bears no relevance to how stuff usually works in a DB. Thanks for the discussion.
[edit]
does saving data to a DB resemble with saving data do a file. to some extent yes. but a DB is much more than that
modified 21-Aug-22 15:30pm.
|
|
|
|
|
Calin Cali wrote: it doesn`t what? (no explicit question in my post) Use the hierarchy that the OS provides. Databases are not files and folders, but lists of stuff called tables.
Calin Cali wrote: If you ask me it`s not a DB job to abstract the idea of files I did not ask, I merely explained it. Any DB has tables and abstracts you away from the FileSystem.
Calin Cali wrote: A DB usually is concerned with how the data is kept within a (single) file. A single entity; SQL Server allows for multiple files on multiple drives, but still represents your DB as a single file. You do not even have to care on what drive your record gets stored, that's a problem for the database.
Calin Cali wrote: Although interesting you DB marginal example bears no relevance to how stuff usually works in a DB. Thanks for the discussion. This is the basic for every database, from SQLite to Oracle
Calin Cali wrote: does saving data to a DB resemble with saving data do a file. to some extent yes. but a DB is much more than that A database file IS a file. You are comparing it in your mind with a text file; that has to be rewritten every time the size changes - that's not efficient enough!
Imagine a text file, a list of names for example. First, you add unused space. If the user now adds a record, you overwrite that space and no need to change the size (and cause fragmentation on disk).
If I'm a db, I store your list of names in alphabetical order. But you have place-names in that list too. So I make another file, where I save those placenames in alphabetical order with their primary key. That allows for quicker lookups. We call those indexes.
Now, please, explain me how "stuff" usually works in a db?
--edit
My bad, I should have explained it more clearly. It's a good question that helps you understand the difference between storing on the OS and in the DB. Most store where they're told to
Feel free to ask; maybe I can learn to respond without feeling attacked
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|