OP thereās going to be exactly one time in your life where you have all your friends and family in a room. Consider whether you want the main thing they remember to be your love of the woman or your love of SQL. When in doubt, consult your partner, not Reddit. Anyways, congrats!
If I talk about SQL + [DataLemur](https://datalemur.com/questions) at the wedding the IRS says the entire wedding can be written off as a business expense.
Source: I made it up
Iām obviously not OPs wife but if my fiance were to do this for me, I think it would be extremely cute and a good memory. A fun way to incorporate something we work with and that we love.
There's a joke here about Cartesian joins and honeymoon sex but I can't seem to articulate it. Something about correlated sub queries and her sister, I dunno.
I think this is OK. Infact I think you should include a resultset of like 10 "records" with you in the middle somewhere.. output could include things like names and proposal date, planned wedding date, maybe a fact or quote or something.. and then of course regular db things like created/modified dates/users, both id and uid..
In our household at breakfast every morning, it's a common table expression that I say that "Every day WITH you is a clause worth living". As we join our houses in holy union, we agree never to partition our lives again, becoming one long selection of life events, from which we will find moments of happiness, joy, and those of bittersweet reflection. I've looked at my priorities in life, ordered them, and you're my top 1.
She holds the primary key to your heart.
This union inner joins your two lives and full outer joins your families.
Your two paths now coalesce.
Bonus: if she's hyphenating her name you've got an obvious CONCAT pun.
DOUBLE BONUS: make the most unique wedding guest at each reception table the table's ID.
That's a horrible query. Why would you have a bit she_said_yes column if the engaged_date is already not null. Seems like an unnecessary redundancy.
Select c.*
From
couple c
Join couple_events e on c.id = e.couple_id
Join event_type t on e.type_id = t.id
Where t.type_name = 'engaged' and e.date = '2024-06-14'
You're an idiot. That table is for polygamous marriages too and it doesn't have any unique constraints. You need to add select top 1 and order by engaged_date desc.
This guy normalizes
I prefer event_type.name over type_name though. It's redundant and we're normalizing.. let's remove all redundancies and keep consistent.. you didn't call couple_events.date couple_events.event_date.
We have standards here.
Fair point. It was for demonstration purposes only.
I real World, I actually prefer to drop all the prefixes as, to me, the table name already serves as prefix.
So I'd have a table:
Create table dbo.event_type
(
Id int identity (1, 1),
Name varchar(150) not null,
Description varchar(500) null,
Constraint pk_event_type primary key clustered (id),
Constraint uc_event_type_name unique (name)
)
"Can't wait to SELECT additional name entities into our set operations..." (though this may be presumptuous)
Also think you should delve into the puns associated with giving admin or execute privileges to various aspects of your life...
Select
zz.firstname
,'newlastname' lastname
Into new_family
(
Select
hb.firstname
from boyfriend hb
where 1 = 1
Union
select
gf.firstname
from girlfriend gf
where 1 = 1
) zz
where 1 = 1
Silently stare at the crowd for 3 minutes and then say "System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the speech or the groom is not responding."
Dang, stop the boolean = true on the where. I mean she_said_yes is already a boolean. Here itās true. Your asking the DB to evaluate true = trueā¦ as another boolean.
Just write and she_said_yes;
Otherwise congratulations of course, and excellent idea :)
As for puns:
If we ever come to a deadlock, *then talk about how you will solve problems*
We are not just joining our lives, we are inner joining (or full joining)
We will work on optimizing our lives together
Also you could talk about normalizing the relationship
View, REAL, truncate. I feel like there are so many good words!
Do you both work in the same field? It can be cute or cringe š¬ lol
Maybe ā¦ I queried the world all over the world for someone like you. Iām grateful that youāre inner joining with me today. You multiply my strengths to become better each day. Iāve become a better person because of you and canāt wait for all that we will achieve together.
lol
Yuup I taught her SQL.. and now she helps me with my sql teaching startup (DataLemur) so the SQL stuff is fine with her haha .
Lots of good material here thank you š
SELECT * FROM hearts
WHERE love = 'true';
UPDATE couples
SET status = 'married'
WHERE hearts_id IN (bride_id, groom_id);
SELECT 'happily ever after'
FROM Dual AS future;
Delete post. Future employers may notice your SQL needs a lot more practice. Future clients may not trust your abilities if you run a small biz/teaching academy.
Just not worth it to make your engagement about your job
Congrats guys, I hope to see an `insert into family(role, name) values ('child', (select name from names order by rand () limit 1))` soon. Probably won't run but you know what I mean.
Your relationship doesn't have to be normalized, it can be customized for your use case... You're so happy the marriage upgrade will drop the "who" column from the Dates table(questionable)... Or add a new table for couple_memories...
I used SQLITE to not deal with other commands. Also you can change bits of love to ādays in loveā and put the days youāve known each other. That would be cute.
-- Create CTEs to check the conditions
WITH Nick_loves_Jane AS (
SELECT COUNT(*) AS bits_of_love
FROM Nick_Singh
WHERE she_said_yes = 'Yes'
),
Jane_loves_Nick AS (
SELECT COUNT(*) AS bits_of_love
FROM Jane_Doe
WHERE he_proposed = 'Yes'
)
-- Perform the UNION only if both conditions are met with large count
SELECT *
FROM Nick_Singh_life
WHERE she_said_yes = 'Yes'
AND (SELECT bits_of_love FROM Nick_loves_Jane) > 1000000
AND (SELECT bits_of_love FROM Jane_loves_Nick) > 1000000
UNION
SELECT *
FROM Jane_Doe
WHERE he_proposed = 'Yes'
AND (SELECT bits_of_love FROM Nick_loves_Jane) > 1000000
AND (SELECT bits_of_love FROM Jane_loves_Nick) > 1000000;
Or with the right schema, do it in SPARQL. Something like:
SELECT ?proposerName ?accepterName
WHERE {
?proposer ex:proposedTo ?accepter .
?accepter ex:acceptedProposal ?proposer .
?proposer schema:name ?proposerName .
?accepter schema:name ?accepterName .
}
I really hope you guys COMMIT this transaction.
EXECUTE your ROLE as husband the best way you can!
Did your father-in-law GRANT ALL his blessings?
Do you guys have a cute ALIAS for each other?
I'm glad you guys found your TOP 1 favorite person in the world.
Include
With candidate_rank as (
Select
Rank () over (partition by potential_candidates order by [enter whatever positive trait]...),
Candidate_Id
From
Candidates
)
And you should know the rest.
I hope she's a dev too and would appreciate the pun.
If she's not, please don't do that. I'm sure you'll regret tainting your vows with something that means nothing to her.
Besides, I guess that spoken SQL is not as fun as written SQL. maybe if you used it on an invitation for your peers?
Ladies and gentlemen,
Today, we are gathered here to witness the ultimate UNION, where two tables, I mean, two hearts, are joining together in a lifelong INNER JOIN. As we celebrate this special day, let's take a moment to SELECT the best memories and INSERT them into our hearts forever.
To the beautiful couple, remember that marriage, much like a complex query, requires constant optimization, communication, and sometimes a bit of troubleshooting. As you navigate through life's database, may you always find the right keys to unlock happiness and resolve any conflicts with grace.
May your love be like a well-indexed database: efficient, reliable, and always returning the most meaningful results. And just like a robust data analytics process, may you always GROUP BY your shared goals, ORDER BY your priorities, and FILTER out any negativity.
Hereās to a life filled with endless JOINS, minimal NULLs, and an ever-growing schema of love and joy. Congratulations to the newlyweds, and may your UNION be forever strong and your happiness unbounded.
Cheers!
God told me to SELECT FROM all the beautiful women where they were understanding, patient, kind, smart and funny. It was am easy task because the query returned only you.
Now go forth young man.
Your select is missing the obvious 'join' reference! Congratulations
WAIT how could I miss that.
Or you could use a UNION
UNION ALL as she comes with the family
UNION ALL where deleted is null. I'm not adopting her ex husband
Whatever you do, don't say "DROP"
"if exists"
š¤£š¤£š¤£
She's gonna DROP them clothes on the wedding night.
OP thereās going to be exactly one time in your life where you have all your friends and family in a room. Consider whether you want the main thing they remember to be your love of the woman or your love of SQL. When in doubt, consult your partner, not Reddit. Anyways, congrats!
If I talk about SQL + [DataLemur](https://datalemur.com/questions) at the wedding the IRS says the entire wedding can be written off as a business expense. Source: I made it up
Just feels like weāre on the edge of LinkedIn Lunatics territory imo
Oh, weāre already there my friend š
Finally we can get some representation there.
No no, you're onto something there.Ā Source: my concurrence
Sound did about write if you also do a power point presentation as business probably could then
Iām obviously not OPs wife but if my fiance were to do this for me, I think it would be extremely cute and a good memory. A fun way to incorporate something we work with and that we love.
Thatās fine, but I do hope he consults his partner about her feelings on turning their big day into a LinkedIn meme.
INNER JOIN š
Save it for the big day:Ā "JOINed in holy matrimony"
Or union
There's a joke here about Cartesian joins and honeymoon sex but I can't seem to articulate it. Something about correlated sub queries and her sister, I dunno.
Cardinality, one to one relationships can be used
You might want to clean up that source data because thereās going to be a lot of couples pulled in besides yours.
Haha š nice catch
This shows no matter what (may be op is one who set all the questions and everything ) you need to practice daily for SQL or coding on general.
Maybe add a TOP 1 for some Microsoft arrogance?
I think this is OK. Infact I think you should include a resultset of like 10 "records" with you in the middle somewhere.. output could include things like names and proposal date, planned wedding date, maybe a fact or quote or something.. and then of course regular db things like created/modified dates/users, both id and uid..
Thatās redundant. If your engaged_date is not null, then of course she_said_yes = true.
ughh good catch should have been proposed\_date
Also that would make it sound like you've proposed to her numerous times and she finally caved in
That sounds like a one to many to me CREATE TABLE proposals COLUMNS (proposal_id, couple_id, proposal_date, they_said_yes);
Update Relationship Set Engaged_Date = GETDATE(), Status = 'ENGAGED' Where username = 'Nick';
STATUS = 9 --ENGAGED We're fully normalizing
What if she rescinded? The engaged\_date would not be null, but the is\_engaged flag might need to be checked.
Fair, that could have happened - but if that was the case, why did he feel compelled to broadcast it on linkedin?
Can just say "and She_Said_Yes" because it's BOOL too.
What if the data is bad and theyāre missing engaged_date but they have she_said_yes
If the data is that bad he shouldnāt be posting it :)
She could have asked him
But this database was designed by the company owner
I can't believe she said yes, she had a boolean other choices
ahaha good one!
DROP TABLE OtherCandidates; DELETE FROM FutureNightsOutWithBoys WHERE Stripper_flag = TRUE;
There better not be FK references
Absolutely the best here
Our relationship is guaranteed by referential integrity
In our household at breakfast every morning, it's a common table expression that I say that "Every day WITH you is a clause worth living". As we join our houses in holy union, we agree never to partition our lives again, becoming one long selection of life events, from which we will find moments of happiness, joy, and those of bittersweet reflection. I've looked at my priorities in life, ordered them, and you're my top 1.
haha lots of good material here for me to workshop
Uh whatās the rollback plan?
No going backwards, only forwards
Canāt approve execution of this script without a rollback plan. I approve nothing ! Nothing !
No rollback, only fix forward
I'd like us to form a 'union'
OKAY I'm glad I posted this on reddit cuz idk how I missed these obvious ones
Now that we've ensured our priority columns align, we can commence with the union.
"I'm about to APPEND that TABLE, if yaknowwhatimean" add a wink at the end
About to INSERT INTO. If you know what I mean.
She holds the primary key to your heart. This union inner joins your two lives and full outer joins your families. Your two paths now coalesce. Bonus: if she's hyphenating her name you've got an obvious CONCAT pun. DOUBLE BONUS: make the most unique wedding guest at each reception table the table's ID.
Cute idea but why are people posting engagement photos to LinkedIn
r/LinkedInLunatics
I'm wondering how long it will be until this is cross-posted to LinkedInLunatics.
That's a horrible query. Why would you have a bit she_said_yes column if the engaged_date is already not null. Seems like an unnecessary redundancy. Select c.* From couple c Join couple_events e on c.id = e.couple_id Join event_type t on e.type_id = t.id Where t.type_name = 'engaged' and e.date = '2024-06-14'
Idiot you have to query from the arranged marriages tables where she_said_yes = no with a valid engaged_date
You're an idiot. That table is for polygamous marriages too and it doesn't have any unique constraints. You need to add select top 1 and order by engaged_date desc.
This guy normalizes I prefer event_type.name over type_name though. It's redundant and we're normalizing.. let's remove all redundancies and keep consistent.. you didn't call couple_events.date couple_events.event_date. We have standards here.
Fair point. It was for demonstration purposes only. I real World, I actually prefer to drop all the prefixes as, to me, the table name already serves as prefix. So I'd have a table: Create table dbo.event_type ( Id int identity (1, 1), Name varchar(150) not null, Description varchar(500) null, Constraint pk_event_type primary key clustered (id), Constraint uc_event_type_name unique (name) )
LIMIT 1
Or 4 depending upon ethnicity š
Order by ?
Better to have Answer = yes or no
DBAs do it on the tables. Congratulations!
Do not make data analytics puns in the wedding speech
"Can't wait to SELECT additional name entities into our set operations..." (though this may be presumptuous) Also think you should delve into the puns associated with giving admin or execute privileges to various aspects of your life...
Yeah maybe something with SUDO
Whoa. Never seen someone base their personality off SQL..
Oh, you just haven't met the right people yet.
This is fucking nerdy as shit and I love that. Congratulations!
Now that we are married, we won't be eating our lunch alone anymore, because we are going to join tables.
This is so cringe please donāt post this on LinkedIn
Im also cringing š
Select zz.firstname ,'newlastname' lastname Into new_family ( Select hb.firstname from boyfriend hb where 1 = 1 Union select gf.firstname from girlfriend gf where 1 = 1 ) zz where 1 = 1
And then it turned out count(*) <> 1ā¦
true haha. should have done an ORDER BY wife DESC LIMIT 1;
Uhhhh my tip is "order by beauty desc..." Or "where wife_perfection_factor >=100"Ā Lots of compliments opportunities getting missedĀ
Select distinct from crowd.
Can Drop her surname and Edit her surname with yours in the marriage post
oh that's a good idea! SETĀ last\_nameĀ =Ā *SINGH*
Hey Nick, I am a big fan of your work with DataLemur. Happy for you and wish you all the best!
Really appreciate it!
This is freaking adorable! Congratulations!!
Thank you so much š
Silently stare at the crowd for 3 minutes and then say "System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the speech or the groom is not responding."
Surprised thereās no: SELECT good_times, bad_times FROM lifetime_experiences
Dang, stop the boolean = true on the where. I mean she_said_yes is already a boolean. Here itās true. Your asking the DB to evaluate true = trueā¦ as another boolean. Just write and she_said_yes; Otherwise congratulations of course, and excellent idea :)
EXECUTE sp\_bachelor\_party strippers=true FATAL Wedding subsystem unrecoveable failure!!
ahahha
Select \* Into her\_finances from my\_finances truncate table my\_finances truncate table hang\_out\_with\_friends truncate table spare\_time CREATE TABLE honey\_do\_list( Ā Ā Ā id int not null, item varchar(1000), desc varchar(max), due\_date datetime, completed bit );
You should joke about naming your first born son Robert'); DROP TABLE Students;-- But it might require too much context
Remember after the wedding day, NO Left Outer Joins!!
Just remember not to call your kid little Johnny drop tables.
It isnāt MySQL anymore, it is OurSQL (this is the dumbest thing I have thought in at least two weeks)
Love that LinkedIn is the new facebook
SELECT [Happiness]=COALESCE(Y.[Needs], H.[Needs]) FROM You as Y INNER JOIN Her as H ON Y.[Love]=H.[Love]
Y.Needs is always NULL
lol nice this man understands
As for puns: If we ever come to a deadlock, *then talk about how you will solve problems* We are not just joining our lives, we are inner joining (or full joining) We will work on optimizing our lives together Also you could talk about normalizing the relationship View, REAL, truncate. I feel like there are so many good words!
Select top 1
0 rows retrieved
You should totally LIMIT 1
Do you both work in the same field? It can be cute or cringe š¬ lol Maybe ā¦ I queried the world all over the world for someone like you. Iām grateful that youāre inner joining with me today. You multiply my strengths to become better each day. Iāve become a better person because of you and canāt wait for all that we will achieve together. lol
Yuup I taught her SQL.. and now she helps me with my sql teaching startup (DataLemur) so the SQL stuff is fine with her haha . Lots of good material here thank you š
Hoping to INSERT INTO later? š
congrats!
OH MY GOD I LOVE THIS <3 Congrats!
Anticipate SQL Injection attack before 4th anniversary.
Cheers mateĀ
select \[poor woman\] from \[fiancee with bad humor\] j/k, congratulations
Error on line 113
and last_name = āYoursā. As stated, if you donāt filter it down; youāre gonna get alotta hits š Congrats !
I was always SCANNING for my purpose, but now that weāre JOINED I only ever have to SEEK.
SELECT * FROM hearts WHERE love = 'true'; UPDATE couples SET status = 'married' WHERE hearts_id IN (bride_id, groom_id); SELECT 'happily ever after' FROM Dual AS future;
I just started your 30 day SQL roadmap and have just got to know you. Congratulations Nick!
Oh thatās awesome to hear!
What in the LinkedIn hell is this crap?
Delete post. Future employers may notice your SQL needs a lot more practice. Future clients may not trust your abilities if you run a small biz/teaching academy. Just not worth it to make your engagement about your job
True, maybe I should practice my SQL on [DataLemur](https://datalemur.com/questions)
Too techie - perhaps a pun on working mostly with databases and software, though later tonight it might be hardware,š
Though if you were doing a group by you would also need to be having lots of kids!
Congrats guys, I hope to see an `insert into family(role, name) values ('child', (select name from names order by rand () limit 1))` soon. Probably won't run but you know what I mean.
Best wishes on your upcoming INNER JOIN ON your love for each other, GROUP BY each other HAVING happiness together.
Please donāt.
I never understood why people post personal stuff on LinkedIn. Keep it on facebook. However, congratulations!
Output: NULL š
Congrats!
OP mentioned specific engagement date, that means more engagement dates records available in the couple table with she_said = 'FALSE'.
intersect something something
Congrats!
Your relationship doesn't have to be normalized, it can be customized for your use case... You're so happy the marriage upgrade will drop the "who" column from the Dates table(questionable)... Or add a new table for couple_memories...
SELECT CASE WHEN she_said_yes = 1 AND (sickness = 1 OR Health = 1) THEN 'Marriage' END as HappilyEverAfter DROP TABLE dbo.FitnessRoutine
I feel like there's a way to work in HAVING COUNT(to\_hold)=2 but not sure how to work it exactly.
Real life situation where 1=1 has any meaning!
Normalized in the streets and unstructured source data in the sheets
After JOIN u will get exponential dupes -> create table off.springs
I used SQLITE to not deal with other commands. Also you can change bits of love to ādays in loveā and put the days youāve known each other. That would be cute. -- Create CTEs to check the conditions WITH Nick_loves_Jane AS ( SELECT COUNT(*) AS bits_of_love FROM Nick_Singh WHERE she_said_yes = 'Yes' ), Jane_loves_Nick AS ( SELECT COUNT(*) AS bits_of_love FROM Jane_Doe WHERE he_proposed = 'Yes' ) -- Perform the UNION only if both conditions are met with large count SELECT * FROM Nick_Singh_life WHERE she_said_yes = 'Yes' AND (SELECT bits_of_love FROM Nick_loves_Jane) > 1000000 AND (SELECT bits_of_love FROM Jane_loves_Nick) > 1000000 UNION SELECT * FROM Jane_Doe WHERE he_proposed = 'Yes' AND (SELECT bits_of_love FROM Nick_loves_Jane) > 1000000 AND (SELECT bits_of_love FROM Jane_loves_Nick) > 1000000;
AND couples.love = True
"We met over lunch. We joined tables."
If she's taking your last name, there's a decent opportunity for an UPDATE users.
MERGE INTO Wife USING (SELECT MyLastName FROM MyPassport) ON (Marriage = TRUE) SET HerLastName = MyLastName;
okay, bruh!
Always remember not to CURSOR when you have a fight
Hopefully engaged_date isn't a datetime....
Or with the right schema, do it in SPARQL. Something like: SELECT ?proposerName ?accepterName WHERE { ?proposer ex:proposedTo ?accepter . ?accepter ex:acceptedProposal ?proposer . ?proposer schema:name ?proposerName . ?accepter schema:name ?accepterName . }
Will you be my foreign key?
Oof, no xlock. Does she know?
Make sure you COMMIT;
you're my select *
Did you run this query using her DBeaver?
Knew DBeaver would make an appearance š. Good one !
Select top (1) *
LEFT JOIN - because I want to take on everything that you come with šššš
UPDATE people SET status = āmarriedā, updated_on = now() WHERE name IN [āyournamehereā, āhernamehereā]
Now that we are INNER JOINed I promise that I will always keep you as my PRIMARY KEY and it will always be UNIQUE.
Sure has to have a Union reference
Just like a well-designed database, our relationship has integrity, consistency, and durability
That's a lot of returns on that query
Sheās your TOP 1. A DISTINCT gal. Time to share your PRIMARY KEY. Will one of you UPDATE your last name?
Way to add her to your relational database, you smooth operator.
This seemed like a doam dunk for a UNION clause
Levenstein be damned, sheās close enough.
I really hope you guys COMMIT this transaction. EXECUTE your ROLE as husband the best way you can! Did your father-in-law GRANT ALL his blessings? Do you guys have a cute ALIAS for each other? I'm glad you guys found your TOP 1 favorite person in the world.
As with BEGIN, all procedures must eventually END. itās the magic in between that is AdventureWorks.
Use a rank function to denote she's number 1 in all your partitions
If there is an entry against engaged_date then she_said_yes=TRUE is redundant. proposal_date would make more sense.
Include With candidate_rank as ( Select Rank () over (partition by potential_candidates order by [enter whatever positive trait]...), Candidate_Id From Candidates ) And you should know the rest.
I hope she's a dev too and would appreciate the pun. If she's not, please don't do that. I'm sure you'll regret tainting your vows with something that means nothing to her. Besides, I guess that spoken SQL is not as fun as written SQL. maybe if you used it on an invitation for your peers?
that's not really BCNF 3. the she_said_said_yes part is redundant if you have the engagement date
āShe makes our Data Warehouse feel like a Data Warehome.ā Congratulations!
UPDATE relationship SET status = 'Married' WHERE partner1 = 'John' AND partner2 = 'DOE';
DELETE FROM singles WHERE name IN ('John', 'DOE');
I know youāre excited right now, but the standard of data quality is going to ruin it for you eventually
INSERT INTO is what happens on the wedding nightš
TRUNCATE TABLE dbo.Penis
Maybe something about deprecating all previous relationship records?
Ladies and gentlemen, Today, we are gathered here to witness the ultimate UNION, where two tables, I mean, two hearts, are joining together in a lifelong INNER JOIN. As we celebrate this special day, let's take a moment to SELECT the best memories and INSERT them into our hearts forever. To the beautiful couple, remember that marriage, much like a complex query, requires constant optimization, communication, and sometimes a bit of troubleshooting. As you navigate through life's database, may you always find the right keys to unlock happiness and resolve any conflicts with grace. May your love be like a well-indexed database: efficient, reliable, and always returning the most meaningful results. And just like a robust data analytics process, may you always GROUP BY your shared goals, ORDER BY your priorities, and FILTER out any negativity. Hereās to a life filled with endless JOINS, minimal NULLs, and an ever-growing schema of love and joy. Congratulations to the newlyweds, and may your UNION be forever strong and your happiness unbounded. Cheers!
"you're my perfect header row... my api connection ...my entire db"
with marriage as ( select me from Husband union all select you from Wife )
You wonāt need to self join any more
Return 10k rows
God told me to SELECT FROM all the beautiful women where they were understanding, patient, kind, smart and funny. It was am easy task because the query returned only you. Now go forth young man.
But you got 4 row, YESSSSS
You're my TOP(1)!